From FORRERJ@frl.orst.edu Fri Feb 03 10:53:03 1995 
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id KAA14043 for 
<hfsig@dingus.n5lyt.datapoint.com>; Fri, 3 Feb 1995 10:53:00 -0600 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOraRFC-OQ0O0PwC; Fri, 3 Feb 95 10:52 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAQ8708 for <HFSIG@tapr.org>; Fri, 3 Feb 1995 01:31:04 
- 0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Fri, 3 Feb 95 8:51:50 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 3 Feb 95 8:51:48 PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Fri, 3 Feb 1995 08:51:39 PST8PDT 
Subject: Parallel tone crest factor 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <E9F1E470AD@fr1.orst.edu> 
Hi All, 


I thought that you might find it interesting that the 39 tone parallel tone 
modems (MIL-STD-188-110) uses the Newman phase sequences. I calculated 

those and compared it to those listed in the MIL-STD docs and they are 
essentially the same. Then plugged the Newman values for initial phases into 
my simulation program and found that the crest factor is less than 6 cB, 
typically 5 dB over a signaling element. The signal also has that apparent 
chirp-like character. Quite exciting to see this magig work. 


I then did the same thing on the DSP implementation and found that one 
cannot actually tell the difference by ear! Sounds pretty much the same as 
a random initial sequence. 


73's 


Johan, KC7WW 
From Rick_Whiting@ATK.COM Fri Feb 03 17:23:45 1995 
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id RAA16775; Fri, 3 Feb 1995 
17:23:36 -0600 
Received: from ATK.COM by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxraXL1-OQQQQUAC; Fri, 3 Feb 95 17:22 CST 
Received: from gateway1 by ATK.COM (8.6.9/8.6.9) 
id RAA27227; Fri, 3 Feb 1995 17:11:52 -0600 
Message-Id: <199502032311.RAA27227@ATK.COM> 
Date: 3 Feb 1995 17:16:11 -0600 
From: "Rick Whiting" <Rick_Whiting@ATK.COM> 
Subject: ARRL Digital Conference 
To: "Post hfsig TAPR" <hfsig@tapr.org>, "Post Netsig TAPR" <netsig@tapr.org> 
CC: "Dave Bushong" <dbushong@wang.com>, "Kay Craigie" <4087290@mcimail.com>, 
"Cornell Drentea" <cdrentea@AOL.COM>, "Gary Garriott" <garyg@vita.org>, 


"David Henderson" <N3E0Y*aN3E0Y@p10.£165.n109.z1.fidonet.org>, 
"Craig McCartney" <73126.3260@compuserve.com>, 

"Bo McLean" <487-1998@mcimail.com>, 

"Richard Muffley" <rmuffley@vita.org>, 

"All Participants NETF" <netf@jriver.com>, 

"Paul Newland" <paul.newland@att.com>, 

"Vic Poor" <71151.720@compuserve.com>, 

"Eric Rosenberg" <ericr@vita.org>, 

"Dale Sinner" <73074.435@compuserve.com>, 

"David Speltz" <5571530@mcimail.com> 


Subject: Time:5:07 PM 
OFFICE MEMO ARRL Digital Conference Date:2/3/95 


Announcement and First Call For Papers 


ARRL DIGITAL COMMUNICATIONS CONFERENCE 
September 8-10 
Arlington, Texas, U.S.A. 


Mark your calendar and start making plans to attend the year's premier event 
in digital communications. The 14th Annual ARRL Digital Communications 
Conference will be held September 8-10, 1995, in Arlington, Texas -- just 
minutes from the Dallas/Ft. Worth Airport. Co-hosts for the Conference are 
TAPR and the Texas Packet Radio Society. 


The ARRL Digital Communications Conference is an international forum for 
radio amateurs and experts in digital communications, networking, and related 
technologies to meet, publish their work, and present new ideas and 
techniques for discussion. Presenters and attendees will have the 
opportunity to exchange ideas and learn about recent hardware and software 
advances, theories, experimental results, and practical applications. 


Anyone interested in digital communications is invited to submit a paper for 

publication in the Conference Proceedings. Presentation at the Conference is 
not required for publication. Papers are due by July 21, 1995, and should be 
submitted to Maty Weinberg, ARRL, 225 Main St., Newington, CT 06111 U.S.A. or 
via Internet at lweinberg@arrl.org. Please contact Maty for detailed format 

requirements. 


The hotel/conference center is extremely well suited and well sited for this 
event. They regularly host other communications-related events and staff 
members are very familiar with the sight of satellite dishes springing up on 
the lawn! They and we are looking forward to a tremendous conference. We 
hope YOU can be part of it! 


For more information on the Conference, registration, and hotel reservations 
please contact TAPR at the address below: 


TAPR 

8987-309 E. Tanque Verde Rd. #337 
Tucson, AZ 85749-9399, U.S.A. 
Phone: (817) 383-0000 


Fax: (817) 566-2544 
Internet: tapr@tapr.org 


[2-3-95] 


From frode@dxcern.cern.ch Tue Feb 14 03:03:35 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id DAA27384 for 

<hfsig@dingus.n5lyt.datapoint.com>; Tue, 14 Feb 1995 03:03:32 -0600 

Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOreJ7r-OO000qYC; Tue, 14 Feb 95 03:00 CST 

Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA24053; Tue, 14 Feb 1995 10:00:45 +0100 

Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AAQ4431; Tue, 14 Feb 1995 10:00:44 +0100 

Date: Tue, 14 Feb 1995 10:00:43 +0100 (MET) 

From: Frode Weierud <frode@dxcern.cern.ch> 

To: HFSIG TAPR <hfsig@tapr.org> 

Subject: Piccolo etc. 

Message-Id: <Pine.ULT.3.91.950214095523 .9344B-100000@dxcern.cern.ch> 

Mime-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi all, 


I just want to distribute a message I got from Adrian Nash, G4ZHZ who has 
written DSP code for the various Piccolo modes. I am hoping to get him to 
join the list as I think he has something to contribute. Perhaps some of 
you would like to contact him and encourage him to join HFSIG. I have 
spoken to Johan about the possibility of porting Adrian's code to the 

PSA sound cards like Cardinal. 


Here is Adrian's message: 


>From nash@camail.ca.nmp.nokia.comTue Feb 14 09:21:45 1995 
Date: Mon, 13 Feb 1995 18:16:30 GMT 

From: Adrian Nash <nash@camail.ca.nmp.nokia.com> 

To: frode@dxcern.cern.ch 

Cc: nash@camail.ca.nmp.nokia.com 

Subject: RE: G-TOR & other modes 


Hello Frode 


Yes, it would be good to get some amateur piccolo going. The software is 
written for the ADSP-2101 and requires 2k program memory and 1k data memory. 
This means it will run on an ADSP-2101 without additional off-chip memory. 
There are several versions: 


ITA52 - 12-tone MFSK 110baud ASCII ITA5 
ITA21 - 6-tone MFSK, Baudot 75 baud as used by UK government (but encrypted 


of course). 

Also, experimental 32-tone Baudot piccolo - the original 1962 MKIII version 
which uses 32 different tones 10Hz apart for the 32 characters of the 

ITA2 code. This is really the rolls-royce of piccolo systems giving ultimate 
performance at the expense of bandwidth. 


The modes are all in one 27C512 boot ROM. 


So far, I have only laboratory tested the ITA5 mode but have found that it 
works very well - 1% bit-error-rate at -10dB SNR - ie you cannot hear the 
signal for the noise. This is of course without error correction. This is 
about 100 times better than a perfect 110bps synchronous FSK link at the same 
SNR in an AWGN channel. 


The software is full-duplex and is currently designed to run on my own 

DSP modem. However, it could very easily be adapted to run on another system. 
I do not have the Cardinal PC sound card that you mention. How much and where 
could I get one from? 


I intend to improve the performance and port the software to the TMS320C50 
TI DSP starter kit. 


The main difference between the way the commercial LA-1117 analogue MFSK 
modem works (no longer used by HM Government) and my modem is that the 
synchronisation is modulation-derived. This means that the modem will 
accurately acquire synchronisation upon a MFSK signal which is sending 

data rather than requiring a period of idle (alternate 500/520Hz tone) signal. 
This makes it much easier for amateur use. 


The only problem I forsee, is that the tuning must be very accurate. However 
most modern radios have at least a 10HzZ synthesizer resolution. My modem 

has a form of visual tuning aid which helps. However, I may develop an 
automatic tuning system which acquires the signal using a form of 

digitally derived AFC. 


I would like to hear more about the other modems you mention, 16 tone and 39 
tone. Has anyone tried the Kineplex type modes which use DPSK and get 4800bps 
through a 3kHz bandwidth? 


My MFSK modem can have a data-mode which uses 16 tones to transmit 

4-bit binary words. With the standard 50ms element length, it will transmit 

at 80bps. Channels can be multiplexed up to occupy an SSB bandwidth. 

A rough calculation suggests that 1200bps can then be sent using 15 MFSK 
channels in a 3kHz bandwidth. This would allow packets to be sent over 

very poor HF channels since MFSK is very good in weak signal/interference and 
selective fading. I think that by applying some error correction (eg CRC) and 
interleaving (to overcome static crashes) we could provide 1200bps packet links 
on HF which have a very good throughput to rival that of pactor and clover. 


If you think other people would be interested in MFSK, please forward my email 
aS appropriate (eg TAPR). 


73, Best Regards 


Adrian G4ZHZ 
Tel: +44 276 419430 
Fax: +44 276 419260 


Nokia Mobile Phones (UK) Ltd 
Ashwood House 

Pembroke Broadway 

Camberley 

Surrey GU15 3SP 

England 


73 Frode, F/LA2RL 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKK 


* Frode Weierud Phone : AL 22 7674794 x 

* CERN, SL Fax : 41 22 7679185 * 

* CH-1211 Geneva 23 E-mail : frode@dxcern.cern.ch 
* 

* Switzerland x 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKAKK 


From paulr@hagar.udc.neweast.ca Tue Feb 14 08:06:21 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id IAA28550 for 

<hfsig@dingus.n5lyt.datapoint.com>; Tue, 14 Feb 1995 08:06:19 -0600 

Received: from hagar.udc.neweast.ca by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOreNqr-O000sLC; Tue, 14 Feb 95 08:03 CST 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA19959; Tue, 14 Feb 95 14:03:02 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA792786812; Tue, 14 Feb 95 10:30:06 nst 

Date: Tue, 14 Feb 95 10:30:06 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 57 Text 

Message-Id: <9501147927 .AA792786812@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: HFSig Status 


Hi, 
I have only just signed onto the HFSIG list. 


I have been reviewing the archives of hfsig, its going to take 
awhile...(there lots - almost 3" of printouts) 


I'm interested in the current status of the new modem, the HF 
simulator, and the like. Has anyone a summary of the results to date? 


I have been working on a project with a "4 of 1of4 tone FSK", i.e. 4 
tones of 16, with an FFT based receiver. Peak amplitude optimization, 
receiver syncronization, protocols for a syncronized scanning system, 
error correction, etc. Preliminary on air testing shows the concept 


works, but needs improvement. Currently 125baud, 4 dibit channels = 
1000bps. 


I saw the early notes on peak optimization, and have achived voltage 
gains of *1.7 to *2.3 on the four tones by precalculating the starting 
phases for all the possible tone combinations and keeping them in a 
lookup table. More info available if anyone is interested. Or better 
yet do you have better results??? 


My hardware is currently TMS320E17 based, with a TMS320C31 design in 
the works. The latter exists only as a bench grade item at present. 


I'm running over Harris RF3200 and Skanti 8000 Radios (nice stuff, 
belongs to the company, glad I didn't have to pay for it), and several 
other brands of Marine HF SSB Radios. 


About Me: 

I'm primarily working on this for commercial reasons - its my job, but 
am open to working in the experimental and development effort, sharing 
test results and experiment time. Our main work is in protocols more 
so than modems, used for ship-shore data reporting here in Canada, and 
helicopter flight following (for Search and Rescue) in places like 
Rwanda and Cambodia. But like everybody else, My boss and our 
customers want higher throughput, but extremely robust at the same 
time. 


Paul G Russell 

St. John's, Newfoundland, Canada 
paulr@neweast.ca 

Fax: Canada (709)576-2125 


"Engineering is a Profession in laziness - How to get 
the most done with the least amount of effort" - PGR 


"You have got to be half crazy, otherwise all the nuts 
in the world will drive you totally insane" - PGR 
corollary: "Which one am I?" 


"Oops, Shouldn't have done that..." - PGR et al 


Oh yea, my opinions are mine, and maybe others as well? 


From FORRERJ@frl.orst.edu Tue Feb 14 17:20:45 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id RAAQ0357 for 

<hfsig@dingus.n5lyt.datapoint.com>; Tue, 14 Feb 1995 17:20:42 -0600 

Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOreWVL-QQOOhVC; Tue, 14 Feb 95 17:17 CST 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 

(8.6.9/8.6.9) with SMTP id HAA14428 for <hfsig@tapr.org>; Tue, 14 Feb 1995 


07:57:15 -0Q800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 14 Feb 95 15:17:36 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 14 Feb 95 15:17:14 
PST8PDT 
From: "Johan Forrer" <FORRERIJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 14 Feb 1995 15:17:13 PST8PDT 
Subject: Re: [HFSIG:238] Piccolo etc. 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <1F8662D5415@frl.orst.edu> 


Frode Weierud <frode@dxcern.cern.ch> wrote: 


> I just want to distribute a message I got from Adrian Nash, G4ZHZ who has 
> written DSP code for the various Piccolo modes. I am hoping to get him to 
> join the list as I think he has something to contribute. Perhaps some of 

> you would like to contact him and encourage him to join HFSIG. I have 
> spoken to Johan about the possibility of porting Adrian's code to the 
> PSA sound cards like Cardinal. 


Just to let everyone know - there is a closeout sale for the Cardinal Pro 
16+ (includes a SCSI 2 CD-ROM interface) at the moment - $39.95 from 

J&R Music. These may not last long. I suspect everyone is getting ready for 
the new generation of DSP-based sound cards. 


I think we all are interested in Adrian's work with MFSK. If he is 
interested, I for one, would be happy to help with the porting of the 
code to the sound card. Let me know if I can help. 


73's 


Johan - KC7WW 
From FORRERJ@frl.orst.edu Tue Feb 14 17:28:39 1995 
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id RAAO0416 for 
<hfsig@dingus.n5lyt.datapoint.com>; Tue, 14 Feb 1995 17:28:35 -0600 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOreWcw-O000jYC; Tue, 14 Feb 95 17:25 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id IAA14499 for <hfsig@tapr.org>; Tue, 14 Feb 1995 
08:05:14 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 14 Feb 95 15:25:31 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 14 Feb 95 15:25:29 
PST8PDT 
From: "Johan Forrer" <FORRERJ@fr1l.orst.edu> 


Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 14 Feb 1995 15:25:24 PST8PDT 
Subject: Re: [HFSIG:239] HFSig Status 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <1F889663FBA@frl.orst.edu> 
Hi Paul, 


Welcome to the group. I think that we all share a lot in common. You 
certainly have a lot of good experiences that we would like to 

hear about. I can appreciate your business interests too - be sure 

to look after those. You will find that most of our work have been to 
provide a platform for experimentors and to advance the technology. 

I would hope that someone would find some of our efforts of use and 
go on to develop products for the amateurs (and commercial for 

that matter). 


Paul Russel wrote: 


> I'm interested in the current status of the new modem, the HF 
> simulator, and the like. Has anyone a summary of the results to date? 


I'll attempt to update you briefly on the present status: 


SIMULATOR: 

I think you will find the main literature references in the archives. 
We had good participation in this discussion that helped find and 
developed necessary principles to accomplish the task. 


In order to test out some of these ideas, I wrote some "C" code for 

the Watterson model. This excersise also explored further DSP 
implementation issues. On the DSP side, I have completed coding and 
testing parts of the code, mostly the Hilbert transformer. There still 
remains a great deal of DSP code to be done. Most of it is relatively 
easy, that is if you have done it before, i.e. the random low frequency 
modulation effects need to be upsampled by a factor roughly 100:1. 

This requires typical multirate techniques, preferably with dithering. 
The random generator also needs a table-lookup algorithm. 

Just have not yet gotten an opportunity completing it all, but thought that 
the modem work needed more attention - I'll get back to it in all 
seriousness soon. 


BTW, all the DSP work for the simultor that I have done so far, is for 
the ADSP 21xx, though would not take much to port to the TAPR DSP-93. I 
have good hope that it will eventually run on our present DSP platforms. 


HF MODEM 
There are several very good ideas floating around, and lately found that 
others actually may have some of it implemented. 


Personnaly, I have been experimenting with the OFDM idea, i.e. 
parallel-tone approach. My program uses 8/8 channels, each channel being 
QDPSK, symbol rate being 31.24 Hz (2*8*31.25=500 bps raw) in a 250 Hz 
channel. It uses a FFT-based demodulator. The idea is, DSP resources 
permitting, to expand to 32 channels (1000 bps raw rate). A rate 1/2 ECC 
will be added. In addition some form of ARQ data-link layer is being 
considered. 


If you are interested - a demo version for this modem running on the sound 
card is available from the TAPR file server: ftp.tapr.org 
tapr/SIG/hfsig/upload/parmdm1.zip 


I have been working on a project with a "4 of 1of4 tone FSK", i.e. 4 
tones of 16, with an FFT based receiver. Peak amplitude optimization, 
receiver syncronization, protocols for a syncronized scanning system, 
error correction, etc. Preliminary on air testing shows the concept 
works, but needs improvement. Currently 125baud, 4 dibit channels = 
1000bps. 


VV VV VV VV 


Sounds interesting - one of those ideas that we have seen here - just 
wonder about the baud rate, however. Have you had good experiences with 
that rate on the lower bands (40/80m) where multipath is so bad? 


I saw the early notes on peak optimization, and have achived voltage 
gains of *1.7 to *2.3 on the four tones by precalculating the 
starting phases for all the possible tone combinations and keeping 
them in a lookup table. More info available if anyone is interested. 
Or better yet do you have better results??? > 


VV VV WV 


I assume you are talking about crest factor optimization? Have you tried 
the Newman sequences - perhaps you have picked up some of our discussions 
and experimental results using that. My experiences for the 39-tone modem 
was that it is possible to get the crest factor down from 10+ dB to around 
6 dB. 


> My hardware is currently TMS320E17 based, with a TMS320C31 design in 
> the works. The latter exists only as a bench grade item at present. 
> 


That is quite a big difference in capability - perhaps you interested in 
floating point capability? The C30 is a really nice chip - smart choice. 


> I'm running over Harris RF3200 and Skanti 8000 Radios (nice stuff, 
> belongs to the company, glad I didn't have to pay for it), and 
> several other brands of Marine HF SSB Radios. 


About Me: 

I'm primarily working on this for commercial reasons - its my job, 
but am open to working in the experimental and development 

effort, sharing test results and experiment time. Our main work 

is in protocols more so than modems, used for ship-shore data 
reporting here in Canada, and 

helicopter flight following (for Search and Rescue) in places like 
Rwanda and Cambodia. But like everybody else, My boss and our 
customers want higher throughput, but extremely robust at the same 
time. 


VVVVV VV VV VV WV 


Sounds an interesting field, Paul. 


> sess es8 ew ew we ee ewww www www eww ewww ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ee ew ew ew ew ew 
> Paul G Russell 

> St. John's, Newfoundland, Canada 

> paulr@neweast.ca 

> Fax: Canada (709)576-2125 

> 

> "Engineering is a Profession in laziness - How to get 

> the most done with the least amount of effort" - PGR 

> 

> "You have got to be half crazy, otherwise all the nuts 

> in the world will drive you totally insane" - PGR 

> corollary: "Which one am I?" 

> 

> "Oops, Shouldn't have done that..." - PGR et al 

> 

> Oh yea, my opinions are mine, and maybe others as well? 

> sessss8 ese we ww ew ew www www www www ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ee ew ew ew ew 
> 

> 

73's 


Johan, KC7WW 

From frode@dxcern.cern.ch Wed Feb 15 02:42:01 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id CAA03941 for 

<hfsig@dingus.n5lyt.datapoint.com>; Wed, 15 Feb 1995 02:41:58 -0600 

Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrefGO-QOQOOPRC; Wed, 15 Feb 95 02:39 CST 

Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AAQQ768; Wed, 15 Feb 1995 09:39:04 +0100 

Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA26902; Wed, 15 Feb 1995 09:38:56 +0100 

Date: Wed, 15 Feb 1995 09:38:53 +0100 (MET) 

From: Frode Weierud <frode@dxcern.cern.ch> 

To: HFSIG TAPR <hfsig@tapr.org> 

Subject: More Piccolo info from G4ZHZ 

Message-Id: <Pine.ULT.3.91.950215093239 .19866B-100000@dxcern.cern.ch> 


Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


I am posting yet another message from Adrian Nash, G4ZHZ. 
I hope to get him to join the list in the next few days. 


Here is a detailed description of his Piccolo modem: 


>From nash@camail.ca.nmp.nokia.comWed Feb 15 08:47:55 1995 
Date: Tue, 14 Feb 1995 18:21:10 GMT 

From: Adrian Nash <nash@camail.ca.nmp.nokia.com> 

To: frode@dxcern.cern.ch 

Cc: nash@camail.ca.nmp.nokia.com 

Subject: RE: G-TOR & other modes 


Hello Again 


Thanks for your email. Yes, I am interested in a copy of the MIL-STD-188 spec. 
I would be very grateful if you could send me a photocopy. I will look up for 
the Cardinal sound card and see if I can get one and adapt my software. 

When I have done this, I will release the source code for the Cardinal Sound 
card. The problem is that I suspect that the 2115 is an ADSP-2105 with a host 
port added. This means that it will have 512 words of data RAM and 1k of 
program RAM. It may be necessary to "prune" the code to fit in this size. 


I think the Analog Devices DSP architecture is very powerful and the assembler 
is very easy to learn for beginners. I would suggest that the ADSP-21xx 

is more powerful than the TMS320C50 or the DSP56002 since it has hardware 

for floating point manipulation, separate barrel shifter, multiplier and 
arithmetic units and ALL instructions take 1 cycle. 


Here is a brief description of how my Piccolo modem works. 


The modem is constructed on a eurocard using wire-wrapping. It uses a 
ADSP-2101 running at 12.288MHz. Other peripherals include an MC68681 DUART 
IC to perform serial comms and drive status LEDs. The ADC is a 12-bit 
AD7871 sampling at 7680kHz. The DAC is 8-bit. NB, a modern 14-bit CODEC 
chip is a far cheaper and a much more satisfactory solution but when I made 
the modem originally they were a bit expensive. The serial port supports 
ASCII at 9600 baud to connect to a PC or other device. It can be configured 
for 75baud Baudot (as used in ITA2 mode), then connect to a teletype. 


The input signal is band-limited to 660Hz using a 3rd order Chebychev analogue 
filter. This is then sampled at 7680Hz by the ADC. The ADSP2101's on-chip 
timer is used to generate regular interrupts and drive the start-conversion 
pin on the ADC using the FLAG_OUT output. 


The demodulator uses a 76-tap FIR filter to filter out excessive bandwidth. 
The bandlimited signal is decimated by 3 down to 2560Hz. This signal is then 
demodulated into the zero-IF complex plane using a quadrature NCO function. 
This function generates cosine/sine waves at 520QHz (the centre of the MFSK 
signalling band) using a 5th order Taylor series approximation. The complex 


signal is now in the range -80Hz to +80Hz corresponding to 380Hz to 680Hz 
inclusive. This includes the 12 MFSK tones 400Hz to 620Hz in 20Hz steps. 

The complex signal is now low-pass filtered using two cascaded FIR filters 
of 56 taps and 117 taps with a stage of decimation in between. The same 

LPFs are used for both I-phase and Q-phase. The bandwidth is a brick-wall 
320Hz. The final output is decimated to 320Hz sample rate (NB: complex plane 
means we CAN sample at the Nyquist frequency) . 


The complex signal is converted to the frequency domain using a complex 
block-floating point, 16-point FFT algorithm. The FFT is a sliding FFT, that 
is a circular buffer is set up. Every sample which enters the buffer, the 
buffer moves along one (FIFO style) and the FFT is executed for EVERY sample. 
The 16 magnitude squared output correspond to a bank of 16 matched filters 
tuned to the 16 tones 20HzZ apart. With the FFT being executed 320 times a 
second, this corresponds to 16 samples per 50ms MFSK symbol. 


The modulation derived synchronisation (MDS) uses the following algorithm to 
extract a 20HzZ sync signal: 
2 
C(n) = M(n) Best 


sum[MAGk(n)] where k=0..15 


ie C(n) the confidence estimate is a ratio of the strongest magnitude 

to the total power in the signal band (add up all the magnitude squared 
results). This gives a real-time estimate about how good the decision is 
going to be about which tone is the one transmitted. (Note this is in effect 
a soft decision so fans of Viterbi decoders as in V32bis modems may be 
interested!) After bandpass filtering this signal, a 20Hz signal results. 

A cross-correlator pattern-matches this to find the peak in the 20Hz signal 
which corresponds to peak confidence. This ensures that the decision is made 
at the optimum time. The pulses from the cross-correlator are used to lock a 
digital phase locked loop algorithm so that if more than one of the same tone 
frequency is transmitted (in which case the 20Hz signal is lost), the modem 
stays in sync. 


The locked clock is used for triggering a decision. The selected tone is 
combined with the previous selected tone to index a look-up table which maps 
the ITA5 (12 tone) or ITA2 (6 tone) characters onto the tone pairs. The 
character is then checked for invalid combinations and idle character 
(500/520Hz). In order to prevent a false transition from the standby state 
to the traffic state, at least 9 idle characters one after the other must 

be received. However, there is a "break-in" switch which sets the modem 
running on a MFSK Tx which is already in progress. If the phase of the tones 
is wrong, another flick of the switch inverts the phase. (NB only a problem 
with the new 6/12 tone system where two tones are used - good old 32 tone 
piccolo only uses one tone so there is no ambiguity.) 


On Tx, the timer interrupt handler reads characters from the UART and uses a 
lookup table to map the characters to tone pairs. These tone numbers are 
loaded into a FIFO buffer. The modulator uses a sine generation algorithm 
very similar to that used for the demodulator. The timer interrupt handler 
is actually called at 15360Hz and is time-shared between Rx tasks (eg 


counter updating and ADC conversion control) and Tx tasks (eg modulator). 


The main-program runs two schedules: Rx control and Tx control. These call 
all the various components (eg demodulator, FFT, sync separation etc etc). 
The main program loop runs at the 320Hz final sample rate (ie 16 times per 
symbol). An Rx buffer buffers up enough 7680Hz input samples to allow 

the processing for one final sample. 


The laboratory tests carried out in 1991/2 at University of Hertfordshire 
showed that in an Added White Gaussian Noise channel (AWGN), the modem 
performed extremely well. The BER was below 1 character error in 10E4 

down to -5dB SNR. Below this the BER grows but is still only 1 character 
error in 10E2 at -10dB SNR. This is far superior to anything possible with 
normal FSK without any form of error correction. An EZ-LAB ADSP-2101 
evaluation board was used as a test generator running a known pseduo-random 
sequence followed in the receiver. This allowed accurate BER measurements. 
On-air testing on a two way link has not been carried out yet. 


However, 

qualitative evaluation using existing MFSK signals found on HF showed that 
although most of the time the encrypted signals could not be decoded, they 
were accurately demodulated with few errors being observed (ie no 

invalid tone combinations) in the presence of strong SSB phone, RTTY and 
broadcast stations. in-band CW tended to cause the most trouble. The modem 
would work on loop-back mode via a channel using a local transmitter and 
receiver. The main problem was actually trying to make the signal weak enough! 
Basically, 100% copy was obtained with a signal that was not even audible. 
This suggests that for normal QSOs, deep fading and interference are likely to 
have very little effect. 


Future improvements 


It was felt that improvements to the floating point arithmetic post-FFT would 
improve the dynamic range of the modem still further. More accurate sine 
generation in the demodulator would reduce the digital equivalent of reciprocal 
mixing which seems to occur with strong out-of-band signals at the ADC input. 

A better CODEC with more resolution would be more convenient though the 

greater resolution would do little more than represent the noise better unless 
the arithmetic and approximation quality of the algorithms can be improved. 


For amateur radio use, some form of automatic signal acquisition would be 
useful. Although not too difficult to tune in accurately manually with a 
tuning aid, due to the variety of amateur HF radio equipment available, some 
form of AFC would help bring the modem on tune. An experimental algorithm has 
been tried particularly with regard to Doppler correction. However, at the 
time, it didn't work very well! 


Full implementation of 16 tone mode. The demodulator uses a 16 point FFT. 
It is therefore just as easily capable of dealing with 16 tones. This would 
be used as a data mode in which 4 bits are conveyed using a tone. Two tones 
would convey an 8 bit word. 


Original 32 tone piccolo. This system uses one tone for every element of the 
ITA2 alphabet. Each tone is 100ms long. The greater integration time 
available gives even better performance than the 6 dual-tone system. This 
system has been implemented partially in DSP. The modulation derived 
synchronisation technique removes the need for 10% AM modulation being 
applied to the MFSK signal as in the original UK FCO system. This enables 
the 32 tone mode to be used with any SSB radio equipment unmodified. 


Well, I hope that has given you more insight into my MFSK activities Frode. 
Please post it up on the HFSIG list (by the way how do I get on that?) if 
you think people would be interested in having a go themselves. 

73, es best regards 

Adrian G4ZHZ 

73 Frode, F/LA2RL 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKAKK 


* Frode Weierud Phone : AL 22 7674794 * 

* CERN, SL Fax : 41 22 7679185 * 

* CH-1211 Geneva 23 E-mail : frode@dxcern.cern.ch 
* 

* Switzerland x 
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From JALOCHA@chopin.ifj.edu.pl Wed Feb 15 07:43:22 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id HAA04795 for 

<hfsig@dingus.n5lyt.datapoint.com>; Wed, 15 Feb 1995 07:43:20 -0600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrejxz-O0003HC; Wed, 15 Feb 95 07:40 CST 

Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA19984; Wed, 15 Feb 1995 14:40:00 +0100 

Date: Wed, 15 Feb 1995 14:20 GMT+1 

Subject: Coding idea for a parallel carrier modem 

To: hfsig <hfsig@tapr.org> 

Message-Id: <67C601F040C13121@chopin.ifj.edu.pl> 

X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org 

X-Vms-To: IN%"hfsig@tapr.ors" 


Just to stimulate the discussion I would like to say an idea I got recently 
about encoding bits and frames onto a multi carrier signals. 


As a base I take the approach to have several regularily spaced 

carriers, each being modulated in phase. 

To decode/encode these signals we do "sliding window" FFT. 

Each window overlaps the one before and the one after by half of its size. 
At every window we change the carrier's phase by +90 or -90 degrees 

to encode Os or 1s respectively. We are limited to 90 degrees shifts 

to keep adjacent symbols fully independent - this is because the windows 


overlap. Thus we encode one bit per FFT window. 


Just to make things more concrete let's assume we take 64 samples per window 
at 9600 Hz sampling rate. This gives up 32 carriers spaced by 150 Hz. 

We only use 15 carriers: the first at 600 Hz and the last at 2700 Hz 

to fill up the 300-3000 Hz spectrum. 

There are 300 FFT windows/second which gives up 300 bits/second/carrier. 
Total raw bit rate would be 300 * 15 = 4500 bps. 


Encoding approach #0 


Let's take the bits from say the HDLC encoder: 
abcdefghijklmnopqrstuvwxyz..... 


and code them straight onto the 15 carriers - like this: 


123 .... <- window number 
1 ap 
2 bq 
3 cr 
4 ds. 
5 et. 
6 fu. 
7 gv. 
8 hw. 
9 i ha 
10 jy. 
11 kz. 
12 1 
13 m 
14 n. 
15 Oo. 
N 


carrier number 


The receiver (after achieving the bit synchronization) would take the FFT 

of every window, compare the phases with the previous window, decode 

15 bits and feed them (with a predetermined order) into the HDLC decoder. 

This approach gives us the full data bandwidth available but no protection 
against bit flips made by noise. 


Encoding approach #1 (We make up a simple FEC) 


We only send 11 data bits per FFT window and the remaining 4 bits we use 
for a simple FEC. 


123 ..... <- window number 


a alw 
2 bm x 
3 cny 
4 doz 
5 ep 

6 fq 

7 gr. 
8 hs. 
9 1s Es 
10 ju. 
11 kv. 
12 AE. 
13 BF. 
14 CG. 
15 DH. 


N 


carrier number 
ABCDEFGH... are the CRC bits designed to correct single bit flips. 


My (possibly naive) way to compute the CRC bits would be: 


X X X xX X X x A 
x xX X xX X x x B 
x x xX X x x x C 
x xX X x x x x D 

“ CRC bits 


abcdefghijk <- data bits 


An "x" indicates that the data bit is xored into the corresponding CRC bit. 
For example A is a xor of a,b,c,g,h,i and k. 


The key is that there are at least two x's above each data bit, so a single 
data flip results in at least two CRC bits being changed and from that 
pattern one can deduce which data bit has been flipped. 


The receiver after decoding the 15 bits at each FFT window would perform 
the error correction and feed the first 11 bits into the HDLC decoder. 
This approach gives us reduced data bandwidth (11 * 300 = 3300 bps) 

but makes a protection against single bit flips per one FFT window. 

Such flips would occure as a result of selective fading, for example, 
when one of the carriers gets much weaker. 

Still we don't have protection against pulse-type noise, which would 
wipe out most likely several bits in one FFT window. 


Encoding approach #2 (Protection against error bursts) 


Interleave the bits ! Well... interleaving requires the receiver 
to synchronize to the interleave frames... or maybe not ? 
We "interleave" the bit the following way: 


. <- Window number 


BP SOONAMAWNHP 
oP 
THEN 
Qao32Ww 
osx: 
oox-, 
HON: 
00 2 - 
TH: 
He 
uu. t+: 
~ & 
rmP<: 


12 


carrier number 


If say window #2 gets corrupted by a spike the flipped bits 1 and b will 
belong to different groups and the FEC will correct them 

in every group seperately. Can this technique be actually called 
"interleaving" ? 


For better protection one can make the "interleave" factor larger, 
like 4. Anyway, I believe it should be at least 2, 

as the bits decoding is differential (that is it relies on 

the previous window). If a spike corrupts one FFT window this results 
in bit flips in that window and in the next one. 


Summary 


I find the proposed scheme capable of correcting data corruption 
resulting from selective fading and pulse type noise. 

The receiver needs just to synchronize to the bit clock 

- it doesn't need to know about SYNC words, magic numbers, etc 

(a higher level HDLC or another frame decoder needs to know that). 
At same time the scheme is simple and not very demanding 

in terms of CPU power or RAM storage. 


The concrete numbers and the FEC method given here are just an example. 
When we increase the number of carriers and make the FEC "stronger" 
(soft decisions ?) the coding would become certainly more efficiant. 
And of course we can run Reed-Salomon on top of that layer... 


Did I reinvent the wheel ? Sure, I did :-) 
Comments ? 


Pawel 
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Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA23401; Wed, 15 Feb 1995 14:57:38 +0100 

Date: Wed, 15 Feb 1995 14:50 GMT+1 

Subject: A coding idea for a parallel carrier modem 

To: hfsig <hfsig@tapr.org> 

Message-Id: <6C0320C5606000E2@chopin.ifj.edu.pl> 

X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org 

X-Vms-To: IN%"hfsig@tapr.ors" 


Just to stimulate the discussion I would like to say an idea I got recently 
about encoding bits and frames onto a multi carrier signals. 


As a base I take the approach to have several regularily spaced 

carriers, each being modulated in phase. 

To decode/encode these signals we do "sliding window" FFT. 

Each window overlaps the one before and the one after by half of its size. 
At every window we change the carrier's phase by +90 or -90 degrees 

to encode Os or 1s respectively. We are limited to 90 degrees shifts 

to keep adjacent symbols fully independent - this is because the windows 
overlap. Thus we encode one bit per FFT window. 


Just to make things more concrete let's assume we take 64 samples per window 
at 9600 Hz sampling rate. This gives up 32 carriers spaced by 150 Hz. 

We only use 15 carriers: the first at 600 Hz and the last at 2700 Hz 

to fill up the 300-3000 Hz spectrum. 

There are 300 FFT windows/second which gives up 300 bits/second/carrier. 
Total raw bit rate would be 300 * 15 = 4500 bps. 


Encoding approach #0 


Let's take the bits from say the HDLC encoder: 
abcdefghijklmnopqrstuvwxyz..... 
and code them straight onto the 15 carriers - like this: 


3 .... <- window number 


DoRWN PR 
mhoQa doo Fr 
Crtn RQ DN 


7 gv 
8 h w 
9 i x 
10 jy 
11 k z 

12 1 

13 m 
14 n. 
Oo. 


carrier number 


The receiver (after achieving the bit synchronization) would take the FFT 

of every window, compare the phases with the previous window, decode 

15 bits and feed them (with a predetermined order) into the HDLC decoder. 

This approach gives us the full data bandwidth available but no protection 
against bit flips made by noise. 


Encoding approach #1 (We make up a simple FEC) 


We only send 11 data bits per FFT window and the remaining 4 bits we use 
for a simple FEC. 


12 3 . <- window number 

1 alw 
2 bm x 
3 cny 
4 doz 
5 ep 

6 fq 

7 gr. 
8 hs. 
9 1b; 
10 yi -Us 4 
11 kv. 
12 AE. 
13 BF. 
14 CG. 
15 DH. 


N 


carrier number 

ABCDEFGH... are the CRC bits designed to correct single bit flips. 
My (possibly naive) way to compute the CRC bits would be: 

X X X xX X X x A 


xX xX X xX X x x B 
x x X X x x x C 


x xX X x x x x D 
“ CRC bits 
abcdefghijk <- data bits 


An "x" indicates that the data bit is xored into the corresponding CRC bit. 
For example A is a xor of a,b,c,g,h,i and k. 


The key is that there are at least two x's above each data bit, so a single 
data flip results in at least two CRC bits being changed and from that 
pattern one can deduce which data bit has been flipped. 


The receiver after decoding the 15 bits at each FFT window would perform 
the error correction and feed the first 11 bits into the HDLC decoder. 
This approach gives us reduced data bandwidth (11 * 300 = 3300 bps) 

but makes a protection against single bit flips per one FFT window. 

Such flips would occure as a result of selective fading, for example, 
when one of the carriers gets much weaker. 

Still we don't have protection against pulse-type noise, which would 
wipe out most likely several bits in one FFT window. 


Encoding approach #2 (Protection against error bursts) 


Interleave the bits ! Well... interleaving requires the receiver 
to synchronize to the interleave frames... or maybe not ? 
We "interleave" the bit the following way: 


123 . <- window number 
1 alw. 
2 bmx. 
3 cny. 
4 doz 
5 ep. 
6 fq. 
7 gr. 
8 hs. 
9 it 
10 ju 
11 k v 
12 AE 
13 BF. 
14 CG. 
15 DH. 


N 


carrier number 


If say window #2 gets corrupted by a spike the flipped bits 1 and b will 
belong to different groups and the FEC will correct them 

in every group seperately. Can this technique be actually called 
"interleaving" ? 


For better protection one can make the "interleave" factor larger, 
like 4. Anyway, I believe it should be at least 2, 

as the bits decoding is differential (that is it relies on 

the previous window). If a spike corrupts one FFT window this results 
in bit flips in that window and in the next one. 


Summary 


I find the proposed scheme capable of correcting data corruption 
resulting from selective fading and pulse type noise. 

The receiver needs just to synchronize to the bit clock 

- it doesn't need to know about SYNC words, magic numbers, etc 

(a higher level HDLC or another frame decoder needs to know that). 
At same time the scheme is simple and not very demanding 

in terms of CPU power or RAM storage. 


The concrete numbers and the FEC method given here are just an example. 
When we increase the number of carriers and make the FEC "stronger" 
(soft decisions ?) the coding would become certainly more efficiant. 
And of course we can run Reed-Salomon on top of that layer... 


Did I reinvent the wheel ? Sure, I did :-) 
Comments ? 


Pawel 
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Date: Wed, 15 Feb 1995 09:33:05 PST8PDT 

Subject: Re: [HFSIG:243] More Piccolo info from G4ZHZ 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <20AAA631BC1@frl.orst.edu> 
Hi Frode/Adrian, 


I am very pleased to hear about this outstanding work. Adrian must 


have devoted a great deal of his time to this project. I'll 
be happy to assist where I can. Hope he manages to subscribe to the 
SIG. 


> I am posting yet another message from Adrian Nash, G4ZHZ. 
I hope to get him to join the list in the next few days. 


Hello Again 


Thanks for your email. Yes, I am interested in a copy of the MIL-STD-188 
spec. 

> I would be very grateful if you could send me a photocopy. I will look up 
for 

> the Cardinal sound card and see if I can get one and adapt my software. 

> When I have done this, I will release the source code for the Cardinal 
Sound 

> card. The problem is that I suspect that the 2115 is an ADSP-2105 with a 
host 

> port added. This means that it will have 512 words of data RAM and 1k of 
> program RAM. It may be necessary to "prune" the code to fit in this size. 


Yes, that is correct about the 2115. The sound card has some 15KW (24-bit) 
zero wait external program memory and 8KW (16-bit) zero wait data memory 
that you will find will meet your needs. 


Perhaps if Adrian could E-mail me directly, we can take up porting 
issues and hardware needs. 


73's 
Johan, KC7WW 


From FORRERJ@frl.orst.edu Wed Feb 15 11:39:43 1995 
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id LAA06261 for 
<hfsig@dingus.n5lyt.datapoint.com>; Wed, 15 Feb 1995 11:39:40 -0600 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrenei-OOOOhRC; Wed, 15 Feb 95 11:36 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAA19359 for <hfsig@tapr.org>; Wed, 15 Feb 1995 
02:16:10 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Wed, 15 Feb 95 9:36:29 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 15 Feb 95 9:36:14 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 


To: hfsig@tapr.org 


Date: Wed, 15 Feb 1995 09:36:07 PST8PDT 

Subject: Re: [HFSIG:244] Coding idea for a parallel carrier modem 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <20AB7C14839@frl.orst.edu> 
Dear Pawel, 


Welcome! Your contribution to the SIG is most welcome too. I am delighted to 
see all the good ideas recently. 


A few comments, for what its worth: 


Pawel Jalocha wrote: 


> Just to stimulate the discussion I would like to say an idea I got 
recently 


> about encoding bits and frames onto a multi carrier signals. 

> 

> As a base I take the approach to have several regularily spaced 

> carriers, each being modulated in phase. 

> To decode/encode these signals we do "sliding window" FFT. 

> Each window overlaps the one before and the one after by half of its size. 
> At every window we change the carrier's phase by +90 or -90 degrees 

> to encode Os or 1s respectively. We are limited to 90 degrees shifts 

> to keep adjacent symbols fully independent - this is because the windows 
> overlap. Thus we encode one bit per FFT window. 

> 

< .... some lines deleted .... > 


I think we are basically talking about one variant of orthogonal frequency 
division multiplexing (OFDM)? Hopefully I can interest you in building 

on the example modem that I have put on the hfsig upload area? This is 
very much along the ideas that you have described and I am sure you will 
have a lot of fun with it. I'll make the source code available if you are 
interested - this will give you a good starting place? 


Although the ideas on coding are quite reasonable and feasible, I am of 
the opinion that we should put our heads together and implement one of 
the modern schemes that were discussed previously on this forum. Perhaps 
you would like to review these ideas and give us some further feedback? 


> Did I reinvent the wheel ? Sure, I did :-) 
> Comments ? 


> Pawel 


Hope to hear from you soon, 


73's 

Johan, KC7WW 

From ewp@world.std.com Wed Feb 15 18:19:46 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id SAA10161 for 

<hfsig@dingus.n5lyt.datapoint.com>; Wed, 15 Feb 1995 18:19:44 -0600 

Received: from europe.std.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrettp-00014SC; Wed, 15 Feb 95 18:16 CST 

Received: from world.std.com by europe.std.com (8.6.8.1/Spike-8-1.0) 
id TAA10285; Wed, 15 Feb 1995 19:16:46 -0500 

Received: by world.std.com (5.65c/Spike-2.0) 
id AA27058; Wed, 15 Feb 1995 19:16:45 -0500 

Date: Wed, 15 Feb 1995 19:16:45 +0001 (EST) 

From: Edson W Pereira <ewp@world.std.com> 

To: hfsig@tapr.org 

Message-Id: <Pine.3.89.9502151917 .A26747-0100000@world.std.com> 

Mime-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


subrcribe rfsig 


From JALOCHA@chopin.ifj.edu.pl Thu Feb 16 10:00:38 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id KAA00Q519 for 

<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 10:00:34 -0600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from dxmint.cern.ch by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrf8d5-00019cC; Thu, 16 Feb 95 10:00 CST 

Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA18551; Thu, 16 Feb 1995 17:00:17 +0100 

Date: Thu, 16 Feb 1995 16:57 GMT+1 

Subject: Re: [HFSIG:247] Re: Coding idea for a parallel carrier modem 

To: hfsig <hfsig@tapr.org> 

Message-Id: <46E7306640600F04@chopin.ifj.edu.pl> 

X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org 

X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>" 


>I think we are basically talking about one variant of orthogonal frequency 
>division multiplexing (OFDM)? 


Yes, that's it. 
To answer this question I needed to look quite some messages backwards 
to decode what the "OFDM" term means exactly :-) 


>Hopefully I can interest you in building 

>on the example modem that I have put on the hfsig upload area? This is 
>very much along the ideas that you have described and I am sure you will 
>have a lot of fun with it. I'll make the source code available if you are 
>interested - this will give you a good starting place? 


For the moment the only DSP platform I can work on is the DSPCARD4. 


I have some start pieces like the FFT code working together with sliding 
window (a left-over from noise suppressors). 

I only need to adapt the "sliding window" so the receiver part is allowed 
to shift in time for symbol-level synchronization. 


>Although the ideas on coding are quite reasonable and feasible, I am of 
>the opinion that we should put our heads together and implement one of 

>the modern schemes that were discussed previously on this forum. Perhaps 
>you would like to review these ideas and give us some further feedback? 


What's "not modern" in my ideas ? :-) 


I just got one idea of a very simple coding for real weak signals. 
Consider my previous example of 15 carriers each carrying 300 bps. 

If we just transmit same stream of bits on every carrier, interleaved 
in time the way I described. The receiver would do majority vote 

(or better sum up all the bits at the analog level and then do 

the hard decision). This way we pass 300 bps in a voice channel 

in a "cruel" way but with high level of redundancy. 

Unfortunately I am not able to make a theoretical comparison 

to some other schemes. Could somebody please do the calculations ? 


Pawel 

From paulr@hagar.udc.neweast.ca Thu Feb 16 10:53:50 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id KAA01302 for 

<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 10:53:47 -0600 

Received: from hagar.udc.neweast.ca by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrf9SU-00019mC; Thu, 16 Feb 95 10:53 CST 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA27196; Thu, 16 Feb 95 16:53:02 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA792969812; Thu, 16 Feb 95 13:23:15 nst 

Date: Thu, 16 Feb 95 13:23:15 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 53 Text 

Message-Id: <9501167929 .AA792969812@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:242] Re: HFSig Status 


Johan Wrote: 

>Personnaly, I have been experimenting with the OFDM idea, i.e. 
>parallel-tone approach. My program uses 8/8 channels, each channel 
>being QDPSK, symbol rate being 31.24 Hz (2*8*31.25=500 bps raw) ina 
>250 Hz channel. It uses a FFT-based demodulator. The idea is, DSP 
>resources permitting, to expand to 32 channels (1000 bps raw rate). A 
>rate 1/2 ECC will be added. In addition some form of ARQ data-link 
>layer is being considered. 

> 

>If you are interested - a demo version for this modem running on the 
>sound card is available from the TAPR file server: ftp.tapr.org 
>tapr/SIG/hfsig/upload/parmdm1.zip 


Johan, 


I retrieved the file, but it is in binary .exe form. Would it be 
possible to obtain the source form for evaluation? 


ftp.tapr.org tapr/SIG/hfsig/upload/parmdm1. zip (pmodem1. zip) 


Also, it seems that most of you (??) are using the same sound card for 
developments. Please give its spec. and I'll order one. Alot easier to 
share experiments. Possibly some long distance trials? 


I operate in the 2-30MHz range on Marine HF Radios (Mostly 3-12MHz), 
with both a whip and a folded L antenna on the building roof here in 
town. Fancier tests may be made from our radio station down the coast 
(~1hr drive). I usually use Voice 300-2700Hz Bands. 


regards (is this what 73's means??) 


> sessss es we ee ew ewww eww ew we eww ew ew ew ew ew ee ew ew ew ew ew ee ew ew ew ew ew ew ew ew ew ew ew ew ew ew ee ew ew ew ew ee ew ew ew ee ew 
> Paul G Russell 

> St. John's, Newfoundland, Canada 

> paulr@neweast.ca 

> Fax: Canada (709)576-2125 

> 

> "Engineering is a Profession in laziness - How to get 

> the most done with the least amount of effort" - PGR 

> 

> "You have got to be half crazy, otherwise all the nuts 

> in the world will drive you totally insane" - PGR 

> corollary: "Which one am I?" 

> 

> "Oops, Shouldn't have done that..." - PGR et al 

> 

> Oh yea, my opinions are mine, and maybe others as well? 

> sess sw ew wwe wwe we ewew www www eww ewww ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew ew 


From FORRERJ@frl.orst.edu Thu Feb 16 11:06:44 1995 
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id LAA01435 for 
<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 11:06:39 -0600 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrf9f1-00019jC; Thu, 16 Feb 95 11:06 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA27304 for <hfsig@tapr.org>; Thu, 16 Feb 1995 
01:45:45 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Thu, 16 Feb 95 9:06:07 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Feb 95 9:06:00 


PST8PDT 

From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 16 Feb 1995 09:05:56 PST8PDT 

Subject: Re: [HFSIG:249] Re: Coding idea for a parallel carrier mode 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <22237720259@frl.orst.edu> 
Dear Pawel, 
<.... some lines deleted .... > 


The past message thread on ODFM would be interesting to you, however, you 
are indeed on the right track. 


For the moment the only DSP platform I can work on is the DSPCARD4. 

I have some start pieces like the FFT code working together with sliding 
window (a left-over from noise suppressors). 

I only need to adapt the "sliding window" so the receiver part is allowed 
to shift in time for symbol-level synchronization. 


VV VV VV MV 


I am also looking at the new M56002 EVM, but too early to say anything yet. 


Be sure to share your ideas on FFT-based noise reduction. I, and others, 
have played with LMS and Wiener filters that appear to do a good job on HF, 
however, have been planning to work on the FFT-based method. These ideas 
come in handy for HF - this is a good place to discuss them too. 


> What's "not modern" in my ideas ? :-) 


Oh no - you are a renaisance man, Pawel. What I mean is that we should 

put our joint efforts towards those schemes that yields the highest 

returns. Simple CRC's, for example is only the first (weak) line of 

defence. We have to include both error detection and correction. That 
probably means convolutional coding or block ECC codes with extensive 
interleaving as you correctly indicated. Soft-decision decoding is probably 
also a good idea. However, I am just repeating what you can read in the past 
message threads for the SIG. I hope I am forgiven? 


I just got one idea of a very simple coding for real weak signals. 
Consider my previous example of 15 carriers each carrying 300 bps. 

If we just transmit same stream of bits on every carrier, interleaved 
in time the way I described. The receiver would do majority vote 

(or better sum up all the bits at the analog level and then do 

the hard decision). This way we pass 300 bps in a voice channel 

in a "cruel" way but with high level of redundancy. 

Unfortunately I am not able to make a theoretical comparison 

to some other schemes. Could somebody please do the calculations ? 


VV VV VV VV VV 


Just for interest sake: the 39-tone MIL-STD-188 modem implements some 

of this. It uses 39 tones, spead out over 3kHz, each tone is phase 

modulated. At the highest rate, each channel represents a single bit stream - 
when needed, the bit rate is dropped in favour of redundancy, where bit 
streams are duplicated, i.e., appears in several channels. This then allowes 
for both frequency and time diversity - very effective. My experiences 

with the analog summing idea, such as implemented in Pactor memory-ARQ, is 
that it is very weak, perhaps 1/2 dB at best in a non-AWGN channel. 


Keep up the good work. 
73's 


Johan, KC7WW 

From gjones@tenet.edu Thu Feb 16 11:26:32 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id LAAO1831; Thu, 16 Feb 

1995 11:26:06 -0600 

Received: from Alice-Thurman.tenet.edu by dptspd.sat.datapoint.com with smtp 

(Smail3.1.29.1 #5) id mOxrf9xr-00019iC; Thu, 16 Feb 95 11:26 CST 

Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id 

LAAQ3238; Thu, 16 Feb 1995 11:25:45 -0600 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199502161725.LAAQ3238@Alice-Thurman.tenet.edu> 

Subject: TAPR.ORG Downtime 

To: tapr-bb@tapr.org (TAPR-BB mailing), hfsig@tapr.org (HF SIG mailing), 
netsig@tapr.org (NETSIG mailing), bbssig@tapr.org (BBS SIG mailing), 
fccreg@tapr.org (fcc), tapr-board@tapr.org (TAPR Board), 
pcs@tapr.org (TAPR PCS Project), dsp-93@tapr.org (DSP-93 Build), 
dsp93dev@tapr.org (DSP93 Development), aprssig@Alice-Thurman.tenet.edu, 
tuc52@tapr.org (TUC-52), tnc95@tapr.org (TNC-95) 

Date: Thu, 16 Feb 1995 11:25:44 -0600 (CST) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 342 


TAPR.ORG Downtime 2/16/95 


The TAPR.ORG system will be moving locations on Monday morning, February 
20th, 1995. 


During this move, the system will be unavailable. A second message will be 
posted when the system is fully operational. 


From FORRERJ@frl.orst.edu Thu Feb 16 12:06:14 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id MAAO2697 for 

<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 12:06:02 -0600 

Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrfAaN-00019sC; Thu, 16 Feb 95 12:05 CST 


Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAA27986 for <hfsig@tapr.org>; Thu, 16 Feb 1995 
02:45:09 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Thu, 16 Feb 95 10:05:31 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Feb 95 10:05:27 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 16 Feb 1995 10:05:24 PST8PDT 
Subject: Re: [HFSIG:250] Re: HFSig Status 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <22335256DDD@frl.orst.edu> 
Hi Paul, 
Pardon the amateur radio terminology, I did not realize that 


you were not a licenced radio amateur - how about getting a 
licence for future on-the-air tests? 


<... some lines deleted ...> 

> I retrieved the file, but it is in binary .exe form. Would it be 
> possible to obtain the source form for evaluation? 

> 

> ftp.tapr.org tapr/SIG/hfsig/upload/parmdm1.zip (pmodem1. zip) 
> 


Since several asked for it, I placed the source code in PMODEM2.ZIP. 


Also, it seems that most of you (??) are using the same sound card for 
developments. Please give its spec. and I'll order one. Alot easier to 
share experiments. Possibly some long distance trials? 


VVV VV 


You have to look for a sound card with the PSA chipset. These include 

the Cardinal Pro 16, Orchid Soundwave32, Western Digital Paradise 16-DSP, 
Adaptec AMExxxx, Wearness Beethoven, and Echo Speech. I recently 

ordered some Cardinal Pro 16 cards from J&R Music (800-221-8180) for $39.95 
on a closeout sale. Not sure how long that will last. Give it a try if you 
wish. 


These cards are basically a 16 MIPS ADSP-2115, memory, and stereo CODEC. 
There also are other alternatives such as the Connection+ phone modems from 
Digicom that has the same DSP chip, though a different CODEC. There are 
some development software around for those as well. I have not, 


however, looked into those at all. 
Hope this helps. 
--Johan 


From paulr@hagar.udc.neweast.ca Thu Feb 16 12:53:57 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id MAA03376 for 

<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 12:52:34 -0600 

Received: from hagar.udc.neweast.ca by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrfBJO-00019sC; Thu, 16 Feb 95 12:51 CST 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA28219; Thu, 16 Feb 95 18:51:22 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA792976911; Thu, 16 Feb 95 15:20:14 nst 

Date: Thu, 16 Feb 95 15:20:14 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 28 Text 

Message-Id: <9501167929 .AA792976911@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:253] Re: HFSig Status 


Johan Wrote: 
><... some lines deleted ...> 


>Since several asked for it, I placed the source code in PMODEM2.ZIP. 


Oops somewhere - The .zip is actually the text description file, 
please upload it again. 


>Pardon the amateur radio terminology, I did not realize that you 
>were not a licenced radio amateur - how about getting a licence for 
>future on-the-air tests? 


I hadn't thought about it .. maybe.. you mean learn more new stuff??!! 
I'll download some of the requirements files to find out just what is 
involved. 

And since this is a ham List, I should use your terminology (meters vs 
MHZ... etc.) 

As for Testing, the Company has several assigned frequencies between 
3&20MHzZ (100m -- 15m ??) that we could use. 


Those Cardinal Cards are all sold out. They have the Orchid 
Soundwave32 for $159.00 This is fully code compatible I assume?? 
I'll order one tomorrow. 


-Paul Russell 


From jmorriso@bogomips.ee.ubc.ca Thu Feb 16 12:54:27 1995 


Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id MAA03399 for 
<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 12:54:02 -0600 
Received: from rflab.ee.ubc.ca by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOxrfBKL-00019cC; Thu, 16 Feb 95 12:53 CST 
Received: from bogomips.ee.ubc.ca by rflab.ee.ubc.ca with uucp 
(Linux Smail3.1.28.1 #1) id mOrfBKs-QO0OSEC; Thu, 16 Feb 95 10:53 PST 
Received: by bogomips.ee.ubc.ca (Linux Smail3.1.29.1 48) 
id mOrfA1LL-0004gQC; Thu, 16 Feb 95 10:17 PST 
Message-Id: <mOrfA1L-0004gQC@bogomips.ee.ubc.ca> 
From: jmorriso@bogomips.ee.ubc.ca (John Paul Morrison) 
Subject: modem for E-M-E? 
To: hfsig@tapr.org 
Date: Thu, 16 Feb 1995 10:17:10 -0800 (PST) 
X-Linux: watch for Linux '95 aka "Helsinki" 
X-Bogomips: 33.55 
X-Mailer: ELM [version 2.4 PL22] 
Content-Type: text 
Content-Length: 529 


Would the modulation techniques being discussed here work with EME (moonbounce)? 


btw the X-Comment: for the list is wrong :-) 


Tucson Amateur Packet Radio HF Speical Interest Group 
ANANNAAN 


BogoMIPS Research Labs -- bogosity research & simulation -- VE7JPM_ -- 
jmorriso@bogomips.ee.ubc.ca ve7jpm@ve7jpm.ampr.org jmorriso@ve7ubc.ampr.org 


From FORRERJ@frl.orst.edu Thu Feb 16 13:17:48 1995 
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id NAAO3850 for 
<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 13:17:44 -0600 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrfBhq-00019vC; Thu, 16 Feb 95 13:17 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id DAA28596 for <hfsig@tapr.org>; Thu, 16 Feb 1995 
03:56:55 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Thu, 16 Feb 95 11:17:16 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Feb 95 11:16:56 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 16 Feb 1995 11:16:49 PST8PDT 
Subject: Replacement PMODEM3.ZIP 

Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <22466256F9D@frl.orst.edu> 


Hi Paul, 


OOPS - sorry about that. Try pmodem3.zip. Sizes look OK now. 


Johan, KC7WW 
From FORRERJ@frl.orst.edu Thu Feb 16 13:35:14 1995 
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id NAA04320 for 
<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 13:35:09 -0600 
Received: from amanda.bus.orst.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrfBye-O000ZVC; Thu, 16 Feb 95 13:35 CST 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id EAA28711 for <hfsig@tapr.org>; Thu, 16 Feb 1995 
04:14:18 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Thu, 16 Feb 95 11:34:40 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Feb 95 11:34:25 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Thu, 16 Feb 1995 11:34:24 PST8PDT 
Subject: Re: [HFSIG:255] modem for E-M-E? 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <224B0C32601@frl.orst.edu> 


Hi John, 


John Paul Morrison wrote: 


> Would the modulation techniques being discussed here work 
with EME (moonbounce)? 


Phil mentioned in one of his early postings on multi-tone schemes, 
that his suggestion originated from EME ideas, so guess there may 
be some usable ideas here. 


For HF, we are basically talking about low symbol rates combined 

with time and frequency interleaved methods to combat the nature of 

the HF channel. I am no expert at EME, but from what I have read, you are 
dealing with very unfavorable S/N (closer to an AWGN channel than HF), 

as well as deep fading phenomena. Although our methods would probably 

be usable, probably not quite addressing the same problems. You may need 
to use similar modulation combined with convoltional coding with very 
large constraint factor - just my $0.02. 


Any other comments? 


> btw the X-Comment: for the list is wrong :-) 


> Tucson Amateur Packet Radio HF Speical Interest Group 
OAV AV AVAVAVATAS 


Could someone tell us how to fix this? Thanks. 
73's 


Johan, KC7WW 
From mcdermot@eagle.aud.alcatel.com Thu Feb 16 14:19:30 1995 
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id OAA05026 for 
<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 14:19:27 -0600 
Received: from aud.alcatel.com by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrfCfa-00019cC; Thu, 16 Feb 95 14:19 CST 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AA21130; Thu, 16 Feb 95 14:19:20 CST 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ2563; Thu, 16 Feb 95 14:19:19 CST 
Date: Thu, 16 Feb 95 14:19:19 CST 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9502162019.AA02563@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:257] Re: modem for E-M-E? 


Hi John, 


John Paul Morrison wrote: 


> Would the modulation techniques being discussed here work 
with EME (moonbounce)? 


Phil mentioned in one of his early postings on multi-tone schemes, 
that his suggestion originated from EME ideas, so guess there may 
be some usable ideas here. 


For HF, we are basically talking about low symbol rates combined 

with time and frequency interleaved methods to combat the nature of 

the HF channel. I am no expert at EME, but from what I have read, you are 
dealing with very unfavorable S/N (closer to an AWGN channel than HF), 

as well as deep fading phenomena. Although our methods would probably 

be usable, probably not quite addressing the same problems. You may need 
to use similar modulation combined with convoltional coding with very 
large constraint factor - just my $0.02. 


Any other comments? 


Johan, KC7WW 


VV VV VV V VV VV VV VV VV VV VV VV VV 


If we are talking strictly AWGN, then it seems there might be two choices: 


1) If bandwidth is no problem, then m-ary FSK provides the best 
possible BER vs. SNR for large values of m, approaching 


Shannon's limit of ‘arbitrarily low error rate' at 

-1.6 dB Eb/No for m=infinite. For finite values of 
large m, convolutional coding and soft-decisions should 
inprove things, but I don't know how much. 


2) If bandwidth is of some concern, then coherent 2PSK, with 
convolutional coding, and soft-decision is optimal within 
a bandwidth no wider than the Nyquist limit 
(channel width of 1/T for alpha=0). Coding is almost 
always a good investment of bandwidth in AWGN. 


Perhaps there are more recent developments that make these two 
limiting cases invalid -- any information onsuch would be of interest! 


Is there another characteristic of the E-M-E path than makes AWGN 
a poor assumption? 


- Tom, N5EG 
From gjones@tenet.edu Thu Feb 16 15:26:56 1995 
Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 
by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id PAAQ5517 for 
<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 15:26:52 -0600 
Received: from Alice-Thurman.tenet.edu by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrfDip-00019sC; Thu, 16 Feb 95 15:26 CST 
Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id 
PAAO4505 for hfsig@tapr.org; Thu, 16 Feb 1995 15:26:44 -0600 
From: Greg Jones <gjones@tenet.edu> 
Message-Id: <199502162126.PAAQ4505@Alice-Thurman.tenet.edu> 
Subject: Re: [HFSIG:257] Re: modem for E-M-E? 
To: hfsig@tapr.org 
Date: Thu, 16 Feb 1995 15:26:44 -0600 (CST) 
In-Reply-To: <224B0C32601@frl.orst.edu> from "Johan Forrer" at Feb 16, 95 01:42:54 
pm 
X-Mailer: ELM [version 2.4 PL23] 
Content-Type: text 
Content-Length: 291 


According to Johan Forrer: 

> > btw the X-Comment: for the list is wrong :-) 

> > Tucson Amateur Packet Radio HF Speical Interest Group 
> ANNNANNAA 


> Could someone tell us how to fix this? Thanks. 
This is one for me -- I'll get the correction submitted. 


Greg 

From srghsjm@GIH.GRACE.CRI.NZ Thu Feb 16 17:39:18 1995 

Received: from dptspd.sat.datapoint.com (dptspd.sat.datapoint.com [130.137.64.2]) 

by dingus.n5lyt.datapoint.com (8.6.9/8.6.9) with SMTP id RAA06519 for 

<hfsig@dingus.n5lyt.datapoint.com>; Thu, 16 Feb 1995 17:39:15 -0600 

Received: from GIH.GRACE.CRI.NZ by dptspd.sat.datapoint.com with smtp 
(Smail3.1.29.1 #5) id mOrfFmt-O000IpC; Thu, 16 Feb 95 17:39 CST 


Received: by GIH.GRACE.CRI.NZ (MX V3.1C) id 3415; Fri, 17 Feb 1995 09:36:15 EST 
Date: Fri, 17 Feb 1995 09:36:13 EST 

From: Stephen McNeill <srghsjm@GIH.GRACE.CRI.NZ> 

To: hfsig@tapr.org 

CC: srghsjm@GIH.GRACE.CRI.NZ 

Message-ID: <Q098C1D2.5EF49580.3415@GIH.GRACE.CRI.NZ> 

Subject: RE: [HFSIG:258] Re: modem for E-M-E? 


In an earlier message Johann said: 


For HF, we are basically talking about low symbol rates combined 

with time and frequency interleaved methods to combat the nature of 

the HF channel. I am no expert at EME, but from what I have read, you are 
dealing with very unfavorable S/N (closer to an AWGN channel than HF), 

as well as deep fading phenomena. Although our methods would probably 

be usable, probably not quite addressing the same problems. You may need 
to use similar modulation combined with convoltional coding with very 
large constraint factor - just my $0.02. 


VV VV VV VV 


Er, I'm no expert on EME either. I've followed most of what's been on 
this group, but what is AWGN ? Did it come up before and did I miss it ? 


EME would-be data users tend to be in two camps: those who would like to 

be able to achieve as high a bit rate as possible for a given power, and 
those who would like to achieve communication at as low a power as possible, 
at ridiculously low bit rates. 


Both are formidible challenges, but I'm interested in the latter. 


Stephen ZL4HG 

From JALOCHA@chopin.ifj.edu.pl Mon Feb 20 13:36:45 1995 

Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 

dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id NAAO3002 for 

<hfsig@tapr.org>; Mon, 20 Feb 1995 13:36:36 -0600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA17884; Mon, 20 Feb 1995 11:47:02 +0100 

Date: Fri, 17 Feb 1995 12:33 GMT+1 

Subject: Re: [HFSIG:251] Re: Coding idea for a parallel carrier mode 

To: hfsig <hfsig@tapr.org> 

Message-Id: <EB2E2E95EQ0601FE0@chopin.ifj.edu.pl> 

X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org 

X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>" 


>Be sure to share your ideas on FFT-based noise reduction. I, and others, 
>have played with LMS and Wiener filters that appear to do a good job on HF, 
>however, have been planning to work on the FFT-based method. These ideas 
>come in handy for HF - this is a good place to discuss them too. 


Well, I made two noise filters: 


One is based on the autocorrelation function. The autocorrelation 


is computed in a continues fashion, then it is used to make a FIR 
filter and the audio is passed through this filter. 

For example for a continues sine wave, the autocorrelation is a cosine 
of same frequency (adding noise makes minimal changes). 

If you put that cosine into the FIR coefficiants (you apply a window 
on the way) your filter will pass only that frequency. 

I find this type of filter not good for speech, but for CW if might 

be just what you need. Unfortunately I never got any comments... 


The other filter is based on the FFT. A 512 point FFT is being continusly 
(by sliding window) computed on the input signal. Then some more or less 
sophisticated criteria (numerous user-selectable options) are applied 

to every frequency bin in order to decide whether it should be muted or not. 
This filter works well for speech (even music with properly selected 
parameters). If somebody wishes to talk about the details I am ready... 


I have a code for both filters running on my DSPCARD4. 
I will attempt a port to the 56002 evaluation board, after I get one. 


>Oh no - you are a renaisance man, Pawel. What I mean is that we should 

>put our joint efforts towards those schemes that yields the highest 
>returns. Simple CRC's, for example is only the first (weak) line of 
>defence. We have to include both error detection and correction. That 
>probably means convolutional coding or block ECC codes with extensive 
>interleaving as you correctly indicated. Soft-decision decoding is probably 
>also a good idea. However, I am just repeating what you can read in the past 
>message threads for the SIG. I hope I am forgiven? 


My ideas are simple but do provide forward error correction 

with time and frequency diversity. I don't want to overcome 

those great ideas - my intention is to provide simple coding 
schemes for initial tests and for future reference. 

After all, it's difficult to jump straight onto those sophisticated 
methods. I imagine, we develope an OFDM modem in few steps: 

1. No FEC - just split the data bits amoung the carriers. 

2. "Simple" FEC with time and frequency diversity. 

3. "Sophisticated" coding to get the last dB's out of the noise. 


When you have these, you let an average amateur compare 
what are the gains and possibly drawbacks :-) of various schemes. 
And you might make them laugh when they find that scheme #1 works best :-) 


>My experiences 
>with the analog summing idea, such as implemented in Pactor memory-ARQ, is 
>that it is very weak, perhaps 1/2 dB at best in a non-AWGN channel. 


Analog summing is indeed "risky" on nowadays HF: if you get a strong 
continues carrier in your passband it will overcome all the other "analog" 
bits (but "smart" techniques could get around this). 

This is not a problem in deep space communication I guess : there, hearing CW 
is like finding a Chevrolet on the Moon :-) (or an ETI...). 


OK. Enough talking... I have a _real_ problem now. I was coding yesterday 


the FFT part of the OFDM modem and got almost stuck at one point: 

which window shape shall I use for "sliding window" ? 

If I use a nice and smooth window I get strong inter-carrier crosstalks. 
I suspect the rectangular window (that is no window at all) would 

make minimal crosstalk. Could somebody help ? 


Pawel 
From FORRERIJ@frl.orst.edu Mon Feb 20 15:04:00 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id PAAQ4827 for 
<hfsig@tapr.org>; Mon, 20 Feb 1995 15:03:52 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id FAA18322 for <hfsig@tapr.org>; Mon, 20 Feb 1995 
05:42:48 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 20 Feb 95 13:03:24 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 20 Feb 95 13:02:57 
PST8PDT 
From: "Johan Forrer" <FORRERIJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 20 Feb 1995 13:02:54 PST8PDT 

Subject: Re: [HFSIG:261] Re: Coding idea for a parallel carrier mode 
Priority: normal 

X-mailer: PMail v3.0 (Rta) 


Message-ID: <2862D444D4A@frl1.orst.edu> 
Hi Pawel, 
Some feedback: 


> 

>One is based on the autocorrelation function. The autocorrelation 

>is computed in a continues fashion, then it is used to make a FIR 

> filter and the audio is passed through this filter. 

>For example for a continues sine wave, the autocorrelation is a cosine 
>of same frequency (adding noise makes minimal changes) . 

> If you put that cosine into the FIR coefficiants (you apply a window 
>on the way) your filter will pass only that frequency. 

>I find this type of filter not good for speech, but for CW if might 

> be just what you need. Unfortunately I never got any comments... 

> 


The LMS (least mean squares) algorithm works very well on voice. If you 
are interested in a really interesting expose on the finer points of 
doing quality filtering - obtain W9GR's code that goes with his QEX/QST 
articles. The articles does not tell you the tricks, however, reading the 
code is very educational. 


>The other filter is based on the FFT. A 512 point FFT is being continusly 
> (by sliding window) computed on the input signal. Then some more or less 
>sophisticated criteria (numerous user-selectable options) are applied 


>to every frequency bin in order to decide whether it should be muted or 
not. 

> This filter works well for speech (even music with properly selected 
>parameters). If somebody wishes to talk about the details I am ready... 
> 


I am queruious about the sample rate are you using Pawel. I thought about 
doing something like this, though found that I, either had to work at a 
lower sample rate, or work with overlapping FFT windows and use up-sampling 
at the output stage (i.e. the output rate of the FFT processor is lower 
than the input sample rate, thus the need for an interpolator filter 

to output the results of the IFFT.) 


> OK. Enough talking... I have a _real_ problem now. I was coding yesterday 
>the FFT part of the OFDM modem and got almost stuck at one point: 

>which window shape shall I use for "sliding window" ? 

> If I use a nice and smooth window I get strong inter-carrier crosstalks. 
>I suspect the rectangular window (that is no window at all) would 

>make minimal crosstalk. Could somebody help ? 

> 


Good question. The basic reason is the requirement for nyquist signaling are 
changed when you convolve with a window function other than a rectangular 
window. Do not use anything but the rectangular window for this type 

of demodulator. 


73's 


Johan, KC7WW 

From gjones@tenet.edu Mon Feb 20 15:23:25 1995 

Received: from Joyce-Perkins.tenet.edu (gjones@Joyce-Perkins.tenet.edu 

[198.213.2.6]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id PAAQ5247; 

Mon, 20 Feb 1995 15:23:18 -0600 

Received: (from gjones@localhost) by Joyce-Perkins.tenet.edu (8.6.9/8.6.9) id 

PAAO9624; Mon, 20 Feb 1995 15:23:16 -0600 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199502202123 .PAAQ9624@Joyce-Perkins.tenet.edu> 

Subject: TAPR.ORG Location Change 

To: tapr-bb@tapr.org (TAPR-BB mailing), bbssig@tapr.org (BBS SIG mailing), 
netsig@tapr.org (NETSIG mailing), dsp-93@tapr.org (DSP-93 Build), 
hfsig@tapr.org (HF SIG mailing), aprssig@tapr.org 

Date: Mon, 20 Feb 1995 15:23:15 -0600 (CST) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 447 


TAPR.ORG has been relocated and has a new numeric IP address of: 
204.96.214.85 


DNS servers should have been updated starting yesterday..... but just in case 


yours is a little slow, you can use the numeric IP until things get fully 
updated. 


The new location allows for a faster connection into Internet which should 
help the site in the long run. 


Thanks to Lee, N5LYT, for his continued help and effort on the TAPR.ORG 
site. 


Cheers - Greg 


From FORRERJ@frl.orst.edu Mon Feb 20 16:11:53 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id QAA06771 for 
<HFSIG@tapr.org>; Mon, 20 Feb 1995 16:11:40 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id GAA18926 for <HFSIG@tapr.org>; Mon, 20 Feb 1995 
06:50:43 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 20 Feb 95 14:11:14 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 20 Feb 95 14:10:53 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Mon, 20 Feb 1995 14:10:53 PST8PDT 
Subject: HF channel simulator - DSP code 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <2874F2E1E69@frl.orst.edu> 
Hi All, 


I have uploaded a very experimental piece of DSP code for the 
HF channel simulator. This is basically for those wishing to 
participate in developing the HF channel simulator. 


You would need a PC sound card (PSA chipset) and the freeware 
Spasm21 assembler for doing further work on the DSP code. A 
C compiler is required to develop the PC code. 


Good luck! 


Johan, KC7WW 

From karn@unix.ka9q.ampr.org Tue Feb 21 04:59:25 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id EAA20336 for 
<hfsig@tapr.org>; Tue, 21 Feb 1995 04:59:16 -0600 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id CAAQ8066; Tue, 
21 Feb 1995 02:59:26 -0800 

Date: Tue, 21 Feb 1995 02:59:26 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 


Message-Id: <199502211059.CAAQ8066@unix.ka9q.ampr.org> 

To: JALOCHA@chopin.ifj.edu.pl 

CC: hfsig@tapr.org 

In-reply-to: <67C601F040C13121@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl) 
Subject: Re: [HFSIG:244] Coding idea for a parallel carrier modem 


Pawel, 
A few (hopefully helpful) comments on your proposal. 


Your baud rate and bits/hz figures seem rather optimistic for all but 
the best HF channels. (See previous discussions about ionospheric 
phase distortion and bandwidth "efficiency" vs power performance) . 


Your FEC code appears to be a (15,11) Hamming code, one of the first 
block FEC codes invented. All Hamming codes have a minimum distance 
between codewords of 3 (any code word differs from all others in at 
least 3 places) and so can correct one error per codeword. 


Hamming codes are not particularly strong. Much better (i.e., more 
error correcting capability and/or lower overhead) codes have since 
been invented. 


Part of the problem is the small block size of your code. All other 
things being equal, bigger blocks (if you can decode them) perform 
better. This has been known since Shannon, so the trick has always 
been to discover large block codes that are practical to generate and 
decode. The Reed-Solomon codes are probably the best known result. 


Your code has a rate of 11/15 or .733. So let's examine a Reed-Solomon 
code with the same rate. I'll pick the (255,187) code over GF(256). 
(RS codes over GF(256) are popular since they give you a convenient 
8-bit symbol size. This in turn implies the 256-1=255 byte blocksize. ) 


This RS code has 255-187 = 68 parity symbols. Any Reed-Solomon code 
can correct up to one-half as many errors per block as it has parity 
symbols. So for this code it can correct up to 34 symbols. That's 
34/255 = 13.3% of the encoded block. Your code can correct only 1/15 = 
6.7% of the block. 


Also, the RS code doesn't mind if all those errors occur in one big 
burst of 34x8 = 272 bits, without any interleaving at all. In fact, it 
xprefersx errors to occur in bursts because it doesn't matter how many 
errors occur in a single Reed-Solomon symbol - even one bad bit 
destroys the symbol, so you might as well heap your other errors there 
too. This explains the well-known burst error correcting capability of 
Reed-Solomon codes. (Interleaving is still often desirable with RS 
coding, though, to reduce the possibility of a single long burst 
beyond this code's capability.) 


But if we consider the pathological case of the bit errors each being 
in a separate symbol, this code could correct only 34 bit errors per 
block, a bit error rate of only 1.7%. So you really have to work out 


the probabilities knowing something about your channel and its error 
statistics before you can decide on a good code. 


Phil 

From JALOCHA@chopin.ifj].edu.pl Tue Feb 21 05:03:35 1995 

Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 

dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id FAA20399 for 

<hfsig@tapr.org>; Tue, 21 Feb 1995 05:03:30 -0600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA18901; Tue, 21 Feb 1995 12:03:11 +0100 

Date: Tue, 21 Feb 1995 12:00 GMT+1 

Subject: Re: [HFSIG:262] Re: Coding idea for a parallel carrier mode 

To: hfsig <hfsig@tapr.org> 

Message-Id: <QB32A7F580603E82@chopin.ifj.edu.pl> 

X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org 

X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>" 


>I am queruious about the sample rate are you using Pawel. I thought about 
>doing something like this, though found that I, either had to work at a 
>lower sample rate, or work with overlapping FFT windows and use up-sampling 
>at the output stage (i.e. the output rate of the FFT processor is lower 
>than the input sample rate, thus the need for an interpolator filter 

>to output the results of the IFFT.) 


OK. Here are some details. Let's assume for the moment that 
I use 9600 kHz sampling and a 512 point FFT. 
I used sliding window of 512 samples in steps of 256 samples. 


The steps are: 

. take 512 samples starting at sample #0 

. multiply these by a sine window (a sine wave from 0 to pi) 

. do the FFT (512 real samples -> 256 complex frequency-domain points) 
process the FFT (remove "useless" frequency components) 

. do the Inverse FFT (we get back 512 real samples) 

. multiply again by the sine window 

place these 512 samples at the outbut buffer starting at #40 


NOoOBWDNPR 


The next cycle is: 
1. take 512 samples starting at sample #256 (note the index moved by 256 not 512)) 
...steps 2-6 are identical... 
7. add these 512 samples to the outbut buffer starting at #256 
(note we _add_ samples to what is already in the output buffer). 


And so on... the next cycles would start at 512, 768, 1024, etc. 


Note that if you skip points 3, 4 and 5 this algorithm effectively 
doesn't do any change to the input stream (well, it does change the first 
256 samples but afterwards there is really no change). 

This is because I use sine-shaped window and I apply it twice during 

the process so the effective window for every batch (512 samples) 

is sin(x)*2. Now imagine several sin(x)%2 shifted by 90 degrees 


- they form a flat line. 
Not a clear explanation, but I hope you can dig out the merits :-) 


Now we put in points 3 and 5 and still we should see no change 
in the data stream as FFT+IFTT doesn change the batch contains. 


>Good question. The basic reason is the requirement for nyquist signaling are 
>changed when you convolve with a window function other than a rectangular 
>window. Do not use anything but the rectangular window for this type 

>of demodulator. 


I agree that with rectangular window we get no crosstalk. 

However, when you get miss-tuned the crosstalk would appear 

and not only in the adjacent carriers. 

Strange things would happen too when you are "miss-tuned" in the symbol 
timing... 


Looking from another point: if we send out data using the reactangular window 
our symbols will have a large spread in frequency spectrum. 

My intuition tells me, the symbol will have half of it's energy 

out of the band intended for that symbol. 

Remember that clicks you hear when listening to the demo multi-carrier modem ? 


I tried to study this problem by numerical simulations using MathCAD 

and I got to a conclusion that you should do proper shaping like sin(x)/x 
or similar. Then your symbols do occupy more-or-less the desired band 

and the time and frequency cross-talk can be made reasonably low 

and affecting only the adjacent carriers. 

However the direct approach to proper shaping implies long FFTs... 

that is for a 256 carriers modem you would need to make 1024 

or 2048 point FFT. I hope there are smarter ways... 


I'm sure there is somebody knoledgeable out there... 


Pawel 

From karn@unix.ka9q.ampr.org Tue Feb 21 05:08:39 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id FAA20447 for 
<hfsig@tapr.org>; Tue, 21 Feb 1995 05:08:31 -0600 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id DAAQ8095; Tue, 
21 Feb 1995 03:09:54 -0800 

Date: Tue, 21 Feb 1995 03:09:54 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199502211109 .DAAQ8095@unix.ka9q.ampr.org> 

To: JALOCHA@chopin.ifj.edu.pl 

CC: hfsig@tapr.org 

Reply-To: karn@qualcomm.com 

In-reply-to: <46E7306640600F04@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl) 
Subject: Re: [HFSIG:249] Re: Coding idea for a parallel carrier modem 


>I just got one idea of a very simple coding for real weak signals. 
>Consider my previous example of 15 carriers each carrying 300 bps. 
>If we just transmit same stream of bits on every carrier, interleaved 


>in time the way I described. The receiver would do majority vote 
>(or better sum up all the bits at the analog level and then do 
>the hard decision). This way we pass 300 bps in a voice channel 
>in a "cruel" way but with high level of redundancy. 

>Unfortunately I am not able to make a theoretical comparison 

>to some other schemes. Could somebody please do the calculations ? 


This is basically "repetition coding". In a nonfading AWGN (additive 
white gaussian noise) channel this has no advantage over just sending 
the data once on a single carrier with full power. But it could have a 
real advantage on a channel with selective fading, assuming the 
transmitter and receiver are both linear and the receiver summing is 
done with sufficent precision such that faded bits are given low 
weight in the decision process. 


You could do even better, though, with a real FEC code instead of 
simple repetition. It would be the same to the modem, but would 
provide considerably better power and bit error rate performance. 


Phil 

From JALOCHA@chopin.ifj.edu.pl Tue Feb 21 05:41:39 1995 

Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 

dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id FAA20679 for 

<hfsig@tapr.org>; Tue, 21 Feb 1995 05:41:33 -0600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA24281; Tue, 21 Feb 1995 12:41:13 +0100 

Date: Tue, 21 Feb 1995 12:38 GMT+1 

Subject: Re: [HFSIG:265] Re: Coding idea for a parallel carrier modem 

To: hfsig <hfsig@tapr.org> 

Message-Id: <10870C5260603E82@chopin.ifj.edu.pl> 

X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org 

X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>" 


Thanks for your remarks Phil, 


>Your baud rate and bits/hz figures seem rather optimistic for all but 
>the best HF channels. 


I fully agree. My idea was: if the 300 bps packet works this scheme 

would work too providing some protection against selective fading, 

burst error and giving quite some bits/second. This is not along the idea 
to copy an unlistenable HF signal. 


Going to more carriers makes the signaling rate lower (which is good) 
and that simple Hamming code carries less overhead. Just a little table: 


carriers data bits CRC bits 


15 11 4 
31 26 5 
63 57 6 
127 120 7 


Anyway that code can only correct single bits which is certainly 
not enough to copy if half of our band is wiped out 
by a speech signal... 


Still, if I code a parallel carrier modem into my DSPCARD4 I will try 
this scheme first because of it's simplicity. Anyway, for the moment 

I just don't know enough details about RS (or any other) code to write 
the coder/encoder myself :-) 


Pawel 

From karn@unix.ka9q.ampr.org Tue Feb 21 05:45:07 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id FAA20694 for 
<hfsig@tapr.org>; Tue, 21 Feb 1995 05:45:03 -0600 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id DAAQ8125; Tue, 
21 Feb 1995 03:46:25 -0800 

Date: Tue, 21 Feb 1995 03:46:25 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199502211146.DAAQ8125@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <9502162019.AA02563@eagle.aud.alcatel.com> 
(mcdermot@eagle.aud.alcatel.com) 

Reply-To: karn@qualcomm.com 

Subject: Re: [HFSIG:258] Re: modem for E-M-E? 


> Is there another characteristic of the E-M-E path than makes AWGN 
>a poor assumption? 


Yeah, lots. Severe multipath fading, for one. The surface of the moon 
is extremely rough. Although the moon rotates on its axis exactly once 
per orbit of the earth, its orbit is slightly eccentric. So as the 
moon rotates at a constant rate on its axis, the small variation in 
its orbital velocity makes it seem to rock from side to side slightly 
as seen from earth. This "libration" causes the relative distances 
from the countless reflecting points on its surface to the user 
stations to not remain constant. A coherent CW carrier is typically 
spread out 50 Hz or so at VHF/UHF frequencies by summing all those 
little random doppler variations. 


Imagine a mirror ball from a dance hall, only much larger and 
thoroughly vandalized by smashing and dark grey spray painting. That's 
the moon at RF. 


This effectively rules out any practical form of phase modulation and 
coherent detection. Noncoherent m-ary FSK would definitely seem to shine 
in this situation. 


Phil 
From karn@unix.ka9q.ampr.org Tue Feb 21 05:49:22 1995 


Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id FAA20708 for 


<hfsig@tapr.org>; Tue, 21 Feb 1995 05:49:17 -0600 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.7/8.6.5) id DAAQ8128; Tue, 
21 Feb 1995 03:51:09 -0800 

Date: Tue, 21 Feb 1995 03:51:09 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199502211151 . DAAQ8128@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <224B0C32601@frl.orst.edu> (FORRERJ@fr1.orst.edu) 

Reply-To: karn@qualcomm.com 

Subject: Re: [HFSIG:257] Re: modem for E-M-E? 


>dealing with very unfavorable S/N (closer to an AWGN channel than HF), 


S/N does not define an AWGN channel. You can have AWGN channel with 
any S/N ratio. It simply means that the channel adds white gaussian 
noise, presumably at a constant power per unit bandwidth. Unless 
otherwise specified, the channel is otherwise completely benign - no 
fading, no interference, no phase distortion, nonlinearities, etc. 


AWGN channels are the most easily analyzed when it comes to coding and 
modulation, but with the exception of satellite communications they 
are not, in general, good models for the real world. 


Phil 
From FORRERJ@frl.orst.edu Tue Feb 21 12:17:19 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id MAA25615 for 
<hfsig@tapr.org>; Tue, 21 Feb 1995 12:17:16 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAA04803 for <hfsig@tapr.org>; Tue, 21 Feb 1995 
02:56:56 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Tue, 21 Feb 95 10:16:40 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 21 Feb 95 10:16:29 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 21 Feb 1995 10:16:21 PST8PDT 
Subject: Collection of ECC programs 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <29B67AA583E@frl.orst.edu> 
Hi All, 


I have placed a collection of error detection/correction programs 
from my library on ftp.tapr.org tapr/SIG/hfsig/download/ecc.zip. 


These are all in C by various authors and includes Reed-Solomon, Golay, 
and BCH. These programs are a good place to start learning about this 
field. 


Phil promised some convolutional code - how about it Phil? 
Hope you find this of use. 
73's 


Johan Forrer, KC7WW 
From mcdermot@eagle.aud.alcatel.com Tue Feb 21 14:01:22 1995 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id OAA28099 for 
<hfsig@tapr.org>; Tue, 21 Feb 1995 14:01:09 -0600 
Received: from eagle.aud.alcatel.com by aud.alcatel.com (4.1/SMI-4.1) 
id AAQ1783; Tue, 21 Feb 95 14:00:47 CST 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ5061; Tue, 21 Feb 95 14:00:47 CST 
Date: Tue, 21 Feb 95 14:00:47 CST 
From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9502212000.AA05061@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Digital downconverter IC 


I received the 1994 Harris DSP Databook last week, and there is 
a very interesting DSP chip in it, the HSP50016. This part is an all-digital 
donwconverter. It is capable of operating up to 52 MSPS. It contains a 32 bit 
NCO, with sint+cos outputs, capable of linear or chirp operation, and it 
multiplies that by the input words. Then it contains both I and Q decimation 
filters (with decimation range 64 to 131072), and I and Q FIR LPFs. The NCO, 
decimators and FIR are all programmable with a significant amount of 
resolution. 


It appears the part would let one digitize the I.F. of a receiver, 
downconvert it to baseband, then decimate the output to a reasonable sampling 
rate. It has a bus interface to a microprocessor for programming. The 
input and output data is 16 bits, and the decimators go up to 66 bits 
in width before scaling. 


Seems like this might be an all-purpose digital receiver back end. 
Call Harris Semiconductor Literature at 1-800-442-7747, or 407-724-3937 
for more info or the DSP Databook. I've no idea what the cost is, comes 
in 48 PGA or 44 PLCC. 


d#tinclude <disclaimer.h>. 
- Tom, N5EG 


From FORRERJ@frl.orst.edu Tue Feb 21 19:08:49 1995 

Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id TAA31032 for 
<hfsig@tapr.org>; Tue, 21 Feb 1995 19:08:45 -0600 

Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id JAA08219 for <hfsig@tapr.org>; Tue, 21 Feb 1995 


09:48:18 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 21 Feb 95 17:08:03 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 21 Feb 95 17:07:55 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 21 Feb 1995 17:07:52 PST8PDT 

Subject: Re: [HFSIG:266] Re: Coding idea for a parallel carrier mode 
Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <2A2434209A5@frl.orst.edu> 
Hi Pawel, 
Good work! 


> OK. Here are some details. Let's assume for the moment that 
> I use 9600 kHz sampling and a 512 point FFT. 
> I used sliding window of 512 samples in steps of 256 samples. 


Thanks for the explanation - I got it now. 
Another question: could you define "useless" frequency components? 


OFDM: You are right about the problems during phasing. May help to look 
at the MIL-STD-188 documentation for ideas. They go into some 

detail on what a sync sequence look like. For one, they do not use 
adjacent channel tones during sync time. 


I also played around a bit with a simulation program to investigate the 
OFDM waveform using raised cosines - the results were not encouraging, 
like you indicated. You trade off performance (assuming you have sync) 
for the ability to sync/bit-track on-the-fly. I am not sure you want 
that when dealing with weak signals. There will be penalties, however, 
especially under multipath conditions. 


You may also get some ideas from J.D. Ralphs' book on MFSK signaling. 

In one example he suggests a sync sequence to obtain bit sync, after which 
the sync detector stays locked for the remainder of the frame. By 
definition, this is non-coherent detection, however, in this situation, bit 
sync also implies phase sync, and thus very close to matched filtering in 
reality. Adrian knows the Piccolo stuff - perhaps he cares to explain how 
he understands this issue. 


The clicks in the OFDM demo is definately due to summing of 39 wave- 
forms from a zero initial phase - the worst you can get. By just changing 
the message content, one can actually hear the difference. I am fairly 
certain that a Newman sequence for initial phases will help here. Not had 
the time to try it yet. 


I uploaded a number of error-correction programs that you may consider. 
Let me know if that is of use. See: 


(ftp.tapr.org tapr/SIG/hfsig/upload/ecc.zip). 
Keep up the good work. 
73's 


Johan, KC7WW 


From nash@camail.ca.nmp.nokia.com Wed Feb 22 04:42:56 1995 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by 

dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id EAA01060 for 

<hfsig@tapr.org>; Wed, 22 Feb 1995 04:42:49 -Q600 

Received: from oueda11.nmp.nokia.com (oueda11.nmp.nokia.com [131.228.233.11]) by 

noknic.nokia.com (8.6.9/8.6.9) with SMTP id MAA21873 for <hfsig@tapr.org>; Wed, 22 

Feb 1995 12:42:12 +0200 

Message-Id: <199502221042 .MAA21873@noknic.nokia.com> 

Received: from camail.ca.nmp.nokia.com by ouedai1.nmp.nokia.com with SMTP 
(1.38.193.3/16.2) id AA26344; Wed, 22 Feb 95 12:33:30 +0200 

Received: from bashful.ca.nmp.nokia.com by camail.ca.nmp.nokia.com with SMTP 
(1.37.109.14/16.2) id AA137629668; Wed, 22 Feb 1995 10:41:08 GMT 

Date: Wed, 22 Feb 1995 10:41:08 GMT 

From: Adrian Nash <nash@camail.ca.nmp.nokia.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:273] Re: Coding idea for a parallel carrier mode 

Cc: nash@camail.ca.nmp.nokia.com 


MFSK Synchronisation 


The MFSK Mk VI modem (Racal LA1117) uses analogue circuitry to synchronise 

to the received signal. The sync circuit consists of two phase locked loops. 
The sync signal itself is an idle character consisting of the tones 500Hz and 
520Hz. This is the same as phase modulating a 510Hz carrier by +/- 90 degrees 
since the tones are orthogonal to each other (ie separation = 1/Ts). 


The first PLL has a centre frequency of 510Hz and tracks the phase shift to 
produce a 10Hz synchronisation signal. This is fed into the second phase 
locked loop which runs at the symbol rate of 10Hz. When the matched filters 
detect that 500/520Hz tones are being received, the second PLL is allowed to 
lock and the sync signal is fed to the quenching circuits of the matched 
filters (a FET across the feedback capacitor in the matched filter circuit.) 


This form of synchronisation is one-shot ie, the idle characters are sent at 
the start of a message and are not necessarily repeated until the end of the 
Tx. The stablility of the frequency standards in the radios and modem needs 
to be 0.1ppm for the system to stay locked over 14 hours. In practice, this 
is actually achieved. 


The 33 tone MFSK system uses 10% amplitude modulation applied to the MFSK 

which is separated by the modem. This is continuous synchronisation but has the 
disadvantages of increasing the bandwidth, putting special constraints on the 
AGC of the receiver and being sensitive to amplitude variations (eg fading.) 


Modern MFSK modems use Modulation Derived Synchronisation (MDS). This is 

a DSP technique which enables good synchronisation to be obtained at any 
point in the Tx without the need for idle characters. This may be appropriate 
to the OFDM modem. It uses the property that the ratio of the magnitude 
squared of the stongest peak in an FFT to the sum of the magnitude squared of 
the other FFT points is a very useful measure of detection confidence and 

can be used as a soft decision. Typically, it will contain a strong component 
at the symbol rate. However, the symbol rate information is lost if the 

same tone is received for two or more symbols. In this case, a digital 

phase locked loop arrangement is used which is kicked into phase by the 
confidence estimate signal and used as a flywheel if the signal fades or 

the same tone is received for consecutive symbols. 


For MFSK it works very well with fast locking. 
Regards 


Adrian G4ZHZ 

From JALOCHA@chopin.ifj.edu.pl Wed Feb 22 05:26:49 1995 

Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 

dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id FAA01228 for 

<hfsig@tapr.org>; Wed, 22 Feb 1995 05:26:45 -Q600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AAQ4468; Wed, 22 Feb 1995 12:26:21 +0100 

Date: Wed, 22 Feb 1995 12:24 GMT+1 

Subject: Re: [HFSIG:273] Re: Coding idea for a parallel carrier mode 

To: hfsig <hfsig@tapr.org> 

Message-Id: <D7B13C9DCO604B44@chopin.ifj.edu.pl> 

X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org 

X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>" 


>Thanks for the explanation - I got it now. 
>Another question: could you define "useless" frequency components? 


OK. A very first approach was to cut off all frequency bins with power 
(power = 142 + Q42) less than a fixed (user-selectable) threshold. 
This was cutting well the background noise if the speech signal 

was significantly stronger than the noise. I noticed you need 

to move the threshold quite high to completely remove the noise. 

With moderate thresholds settings you could still hear occasionally 
very characteristic "bleep, bleep" sounds when single channels 

were coming above the threshold. 

I didn't notice much improvement in readability - for weak signals 

the weaker speech pieces could get cut off completely. 


Then I tried to make the cut "smoother": if the bin power was above 
the threshold I just let it pass. If below I multiplied it by a factor: 
bin_power/threshold_power. This way nothing is cut off, it's only 
attentuated propotionaly to it's "“un-importance". 


Then I noticed my radio doesn't pass the audio spectrum in a uniform 


fashion... I developed a way to estimate the noise level for every 
frequency bin individually and my threshold was proportional 

to that noise level. This improved fidelity on AM stations (especially 

on music). The side effect which I did not expect was that a dead carriers 
got cut off because they were assumed "noise" - makes some sense 

by the way :-) 


Then I wanted to kill these bleeps... so I tried to correlate 

the data in time. I required that a given frequency passes the threshold 
in two (a user-selectable parameter) consecutive FFT samples. 

I got certain improvement that way, but I am really not sure whether 

it was worth the effort. Correlating on a longer time scale 

could be usefull for CW signals... 


I came back to speech/music fidelity again: if a given freuquency 

got triggered I left it open for some time after the trigger 

so the falling-type sounds (musical instruments) could be passed with 
least distortions. For even less distortion I was openning 

the frequency before the trigger (of course you have to use 

a delay tap for that). A yet another option was that the filter 

would open the adjacent bins to the triggered ones. 

All that attriubuted to fidelity but it let as well more noise 

to come through, so the final effect was always some sort of trade-off. 


The major disadvantage of that automatic background estimation 

was that the filter needed about 5-10 seconds to adjust itself to 
new conditions and it was sensitive to fast amplification changes 

- like when a spike was "pushing up" the AGC. 

I have some ideas about how to cure these effects but for the moment 
I got involved in the multi-modem idea :-) 


By the way, these games with threshold setting might be usefull 
for non-coherent type multi-carrier modems... 


>I also played around a bit with a simulation program to investigate the 
>OFDM waveform using raised cosines - the results were not encouraging, 
>like you indicated. You trade off performance (assuming you have sync) 
>for the ability to sync/bit-track on-the-fly. I am not sure you want 
>that when dealing with weak signals. There will be penalties, however, 
>especially under multipath conditions. 


My conclusions are that you have to do longer FFTs: at least 2 times 
longer and then use every second carrier or better 4 times longer 
and use every fourth carrier. The unused carriers will be usefull 
on the receiver side for mis-tune estimation. 

The simulations I have done tell me that it might be worth to 

send symbols at a bit lower rate than the maximum one. 

For example if I use a sin(x)/x type window I have hardly any 
frequency crosstalk, and the time crosstalk has a local zero point 
at about 1.2 the minimum symbol spacing. 

The other way to do the trade-off is to use say every fifth carrier 
not every forth, if you do 4 times longer FFTs. 


If you stick to the "trivial" FFT aproach with a rectangular window, 
then a dead carrier somewhere in the receiver passband with affect 
more or less all the frequency channels (as seen by the receiver). 
If the carrier is strong enough it would wipe out all the bits 

- even the strongest ECC code is not going to help you :-) 


Pawel 
From taprmail@dingus.n5lyt.datarace.com Wed Feb 22 10:24:24 1995 
Received: from paccomm.com ([163.125.30.1]) by dingus.n5lyt.datarace.com 
(8.6.9/8.6.9) with SMTP id KAAOQ5795 for <hfsig@tapr.org>; Wed, 22 Feb 1995 
10:24:09 -0600 
Received: from lantz.com by paccomm.com (TNOS1.11b14) with SMTP 
id AA25069 ; Tue, 21 Feb 95 18:17:37 UTC 
Received: from dingus.n5lyt.datarace.com by lantz.com with smtp 
(Smail3.1.28.1 #52) id mOrgjsp-Q004wVC; Mon, 20 Feb 95 20:59 EST 
Received: (from taprmail@localhost) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) id 
TAA13588 for HFSIG@PACCOMM.COM; Mon, 20 Feb 1995 19:57:06 -0600 
From: TAPR MAIL MGMT ACCOUNT <taprmail@dingus.n5lyt.datarace.com> 
Message-Id: <199502210157 .TAA13588@dingus.n5lyt.datarace.com> 
Subject: [HFSIG] HFSITG@PACCOMM.COM 
To: HFSIG@PACCOMM.COM 
Date: Mon, 20 Feb 1995 19:56:58 -0600 (CST) 
X-Mailer: ELM [version 2.4 PL23] 
Content-Type: text 
Content-Length: 438 


Dear TAPR Listserv Member: 


This is a monthly message to check to see that you are still active on 
this Mail list and to uncover any bad Internet addresses. 


To stay with this mail list, simply DELETE this message. No other action is 
required. ss eee enn ne 


If you want to unsubscribe, send e-mail to listserv@tapr.org with a message of 
unsubscribe listname, where listname is the name of the list. 


Cheers - TAPR 


From karn@qualcomm.com Wed Feb 22 19:47:25 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id TAA10568 for 
<hfsig@tapr.org>; Wed, 22 Feb 1995 19:47:22 -Q600 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id RAA20849; 
Wed, 22 Feb 1995 17:49:07 -0800 

Date: Wed, 22 Feb 1995 17:49:07 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199502230149.RAA20849@servo.qualcomm. com> 

To: JALOCHA@chopin.ifj.edu.pl 

CC: hfsig@tapr.org 

In-reply-to: <10870C5260603E82@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl) 
Subject: Re: [HFSIG:268] Re: Coding idea for a parallel carrier modem 


>Going to more carriers makes the signaling rate lower (which is good) 
>and that simple Hamming code carries less overhead. Just a little table: 


Yes, the Hamming code overhead is lower as you increase the blocksize. 
But since it can correct only one error per block, its effectiveness 
also decreases with increasing block size. 


>I just don't know enough details about RS (or any other) code to write 
>the coder/encoder myself :-) 


No need. Two years ago, Paul Flaherty, N9FZX, wrote a Reed-Solomon 
encoder/ decoder routine that he has made freely available. It's 
available from several archive sites, e.¢g., 


ftp://labrea.stanford.edu/pub/gnu/ecc-1.2.1.tar.gz 
ftp://pdq.coe.montana.edu/pub/mirrors/prep-gnu/ecc-1.2.1.tar. gz 


Archie lists several other sites. 


Phil 


From karn@qualcomm.com Wed Feb 22 20:03:37 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id UAA10812 for 
<hfsig@tapr.org>; Wed, 22 Feb 1995 20:03:34 -0600 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAA21014; 
Wed, 22 Feb 1995 18:05:32 -0800 

Date: Wed, 22 Feb 1995 18:05:32 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199502230205.SAA21014@servo.qualcomm. com> 

To: FORRERJ@fxr1.orst.edu 

CC: hfsig@tapr.org 

In-reply-to: <29B67AA583E@frl.orst.edu> (FORRERJ@frl1l.orst.edu) 

Subject: Re: [HFSIG:271] Collection of ECC programs 


>Phil promised some convolutional code - how about it Phil? 
One of these days...I'm thinking of turning it into a Dr. Dobbs' article... 


Phil 

From karn@qualcomm.com Wed Feb 22 20:07:22 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id UAA10849 for 
<hfsig@tapr.org>; Wed, 22 Feb 1995 20:07:12 -0600 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAA21022; 
Wed, 22 Feb 1995 18:08:58 -0800 

Date: Wed, 22 Feb 1995 18:08:58 -0800 

From: Phil Karn <karn@qualcomm.com> 

Message-Id: <199502230208 .SAA21022@servo.qualcomm. com> 

To: JALOCHA@chopin.ifj.edu.pl 


CC: hfsig@tapr.org 
In-reply-to: <EB2E2E95EQ601FEQ@chopin.ifj.edu.pl> (JALOCHA@chopin.ifj.edu.pl) 
Subject: Re: [HFSIG:261] Re: Coding idea for a parallel carrier mode 


>which window shape shall I use for "sliding window" ? 


There are many window shapes. All are compromises. I can cite any number of 
textbooks that discuss them, do you have good references? 


Phil 

From karn@qualcomm.com Wed Feb 22 20:10:08 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id UAA10898 for 
<hfsig@tapr.org>; Wed, 22 Feb 1995 20:10:01 -0600 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id SAA21038; 
Wed, 22 Feb 1995 18:11:56 -0800 

Date: Wed, 22 Feb 1995 18:11:56 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199502230211.SAA21038@servo.qualcomm. com> 

To: hfsig@tapr.org 

Subject: misconfigured mail reflector 


The software that handles the hfsig mailing list is incorrectly 
configured. It adds a "Reply-To: hfsig@tapr.org" header to the front 
of every message it relays. This makes it tedious to reply privately 
to the sender of a message, as I have to edit the destination address 
manually. 


Can whoever maintains the mailing list please look into fixing this? Thanks. 
Phil 


From k5yfw@k5yfw.ampr.org Wed Feb 22 22:22:14 1995 

Received: from k5yfw.ampr.org (k5yfw.ampr.org [44.76.2.88]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id WAA12437 for 
<hfsig@tapr.org>; Wed, 22 Feb 1995 22:22:04 -0600 

Date: Wed, 22 Feb 95 22:15:03 CST 

Message-Id: <2617@k5yfw.ampr.org> 

From: k5yfw@k5yfw.ampr.org (Walter D. DuBose - K5YFW) 
Reply-To: k5yfw@sat.n5lyt.ampr.org 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:280] misconfigured mail reflector 
In-Reply-To: Your message of Wed, 22 Feb 1995 20:12:52 -0600 
X-Mailer: Bdale's Mailer version PA3AZK.940404 (MSDOS) 


In message <199502230211.SAA21038@servo.qualcomm.com> you write: 

The software that handles the hfsig mailing list is incorrectly 
configured. It adds a "Reply-To: hfsig@tapr.org" header to the front 
of every message it relays. This makes it tedious to reply privately 
to the sender of a message, as I have to edit the destination address 
manually. 


VV VV VV MV 


Can whoever maintains the mailing list please look into fixing this? Thanks. 


> Phil 


Phil, 


I believe Lee, N5LYT, maintains it. I will refer this to him. I 
believe that the actual hosts is dingus.n5lyt.datarace.com and/or 
dingus.n5lyt.ampr.org (same box). 


Walt (k5yfw@sat.n5lyt.ampr.org) 
From mamurphree@space.honeywell.com Thu Feb 23 09:02:43 1995 
Received: from £151mail.space.honeywell.com (f£151mail.space.honeywell.com 
[130.181.12.102]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id JAA14618 
for <hfsig@tapr.org>; Thu, 23 Feb 1995 09:02:38 -0600 
Received: from £151p01.space.honeywell.com by f151mail.space.honeywell.com with 
SMTP 
(1.38.193.5/16.2) id AA21478; Thu, 23 Feb 1995 08:27:34 -0500 
Received: by smtpdos.space.honeywell.com with Microsoft Mail 
id <2F4CB4B7@smtpdos.space.honeywell.com>; Thu, 23 Feb 95 08:15:51 PST 
From: Murphree Michael A <mamurphree@space.honeywell.com> 
To: hfsig <hfsig@tapr.org> 
Subject: RE: [HFSIG:280] misconfigured mail reflector 
Date: Thu, 23 Feb 95 08:23:00 PST 
Message-Id: <2F4CB4B7@smtpdos.space.honeywell.com> 
Encoding: 15 TEXT 
X-Mailer: Microsoft Mail V3.0 


>The software that handles the hfsig mailing list is incorrectly 
>configured. It adds a "Reply-To: hfsig@tapr.org" header to the front 
>of every message it relays. This makes it tedious to reply privately 
>to the sender of a message, as I have to edit the destination address 
>manually. 


It gets worse.... Those of us(?) using Microsoft Mail do not get the headers 
and 

can not reply to or even identify the sender unless it is in the From or To 
fields.. 


Stuck in the Gates of Hell, 

Mike 

From JALOCHA@chopin.ifj.edu.pl Thu Feb 23 09:15:43 1995 

Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 

dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id JAA14953 for 

<hfsig@tapr.org>; Thu, 23 Feb 1995 09:15:31 -0600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA11898; Thu, 23 Feb 1995 13:41:42 +0100 

Date: Thu, 23 Feb 1995 12:56 GMT+1 

Subject: Re: [HFSIG:279] Re: Coding idea for a parallel carrier mode 


To: hfsig <hfsig@tapr.org> 

Message-Id: <A568F1CBCO605D60@chopin.ifj.edu.pl> 
X-Envelope-To: @DXMINT.CERN.CH:hfsig@tapr.org 
X-Vms-To: IN%"<@DXMINT.CERN.CH:hfsig@tapr.org>" 


>There are many window shapes. All are compromises. I can cite any number of 
>textbooks that discuss them, do you have good references? 


After re-thinking the problem, my current view is: 


On the receiver side the window+FFT works like a FIR filter: 

for a given frequency bin we convolute the input signal with 

a shape = sin(2*xpixfxt) * window_shape(t) where £ is the frequency 
corresponding to this bin: f£ = bin_index/FFT_lenxsampling_rate 
(bin_index = 0..FFT_len/2-1). 


Now, the problem is "reduced" to finding the FIR shape such that: 

- the spectral response is rather flat within the bin's passband 

- the spectrum tails going to adjacent bins are minimal 

- the crosstalk between succesive symbols (on same carrier) is minimal 
- the shape is rather short (so we don't have to make long FFTs) 

You can't have all at once - certainly comprimises are needed. 

I believe you can't achieve reasonable performance by doing 

the FFT with the "minimal" length - you need to at least double it. 


Sounds like an academic (but still non-trivial) problem... 
any good student out there ? :-) 


Pawel 

From karn@qualcomm.com Fri Feb 24 21:04:40 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id VAA29933 for 
<hfsig@tapr.org>; Fri, 24 Feb 1995 21:04:33 -0600 

Received: (karn@localhost) by servo.qualcomm.com (8.6.9/QC-BSD-2.5) id TAA13111; 
Fri, 24 Feb 1995 19:06:10 -0800 

Date: Fri, 24 Feb 1995 19:06:10 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199502250306.TAA13111@servo.qualcomm. com> 

To: hfsig@tapr.org 

Subject: Indian HF modem 


I just got a copy of a very interesting technical report from Bharat 
Electronics, an Indian company. They did a 2400 bps HF radio modem for 
the Indian military that uses MIL-STD-188-110 modulation (16 tone 
version) plus a (15,9) reed-solomon code over GF(16). On top of that 
is an interesting hybrid arq/fec scheme. The modem and coder was 
implemented on a TMS320C30, the arq stuff on a PC. 


I've run off 5 copies. I could bring them with me to the TAPR meeting 
next weekend in St. Louis, for those of you who are coming. 


Phil 


From FORRERJ@frl.orst.edu Sat Feb 25 01:36:18 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id BAA31583 for 
<hfsig@tapr.org>; Sat, 25 Feb 1995 01:36:14 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id QAAO2607 for <hfsig@tapr.org>; Fri, 24 Feb 1995 
16:15:02 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Fri, 24 Feb 95 23:34:55 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 24 Feb 95 23:34:44 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Fri, 24 Feb 1995 23:34:35 PST8PDT 
Subject: Re: [HFSIG:284] Indian HF modem 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <2FOB7F64EBA@frl.orst.edu> 
Hi Phil, 


I'll be interested in seeing the docs. Will appreciate a copy - See you in 
St. Louis. 


73's 


Johan KC7WW 
From BobH@eworld.com Sat Feb 25 13:20:13 1995 
Received: from hp1.online.apple.com (hp1.online.apple.com [192.215.65.17]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id NAAQ0967 for 
<hfsig@tapr.org>; Sat, 25 Feb 1995 13:20:08 -0600 
From: BobH@eworld.com 
Received: by hp1.online.apple.com 
(1.38.193.5/16.2) id AA12668; Sat, 25 Feb 1995 11:18:49 -0800 
X-Mailer: AOS Mailer 
Sender: "BobH" <BobH@eworld.com> 
Message-Id: <9502251118.tn09091@eworld. com> 
To: hfsig@tapr.org 
Date: Sat, 25 Feb 95 11:18:46 PST 
Subject: No Subject 


Two items of interest: 

> To be filed with the growing list of affordable hardware options for DSP-- 
EZDSP-Lab products from Real Time Signal Processing Inc. (403)250-2407, FAX 
(403) 250-6711. 

Stand-alone board with Analog Devices ADSP-2115 and AD1847 Codec for $99. 
Price includes PC download utility, Analog Devices' Assembler, Linker and 
Prom Splitter but not the Simulator. Don't know what debug environment is 
like. ADSP-2181/AD1847 for $199. 

> Paper I haven't got yet but looks interesting-- "Soft Decision Decoding of 
Reed-Solomon Codes Using Trellis Methods" IEE PROC-COMM Oct. 94 

wm6h 


From gwyn@paccomm.com Sat Feb 25 16:38:27 1995 

Received: from paccomm.com ([163.125.30.1]) by dingus.n5lyt.datarace.com 

(8.6.9/8.6.9) with SMTP id QAA02653 for <hfsig@tapr.org>; Sat, 25 Feb 1995 

16:38:19 -0600 

X-BBS-Msg-Type: P 

Date: Sat, 25 Feb 95 17:22:30 UTC 

Message-Id: <622@paccomm.com> 

From: gwyn@paccomm.com (Gwyn Reedy, W1BEL) 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:284] Indian HF modem 

In-Reply-To: your message of Fri, 24 Feb 1995 21:14:12 -0600. 
<601@paccomm. com> 


sounds very similar to the Harris 39 tone modem which used 320c25s I 
think. Harris moved to 320C50s later on, but had a lot of trouble 
with early chips. 


I'd be very interested in seeing a copy of the report. 


C U in St. Louis, 


Gwyn 
Gwyn Reedy, WIBEL  — gwyn@paccomm.com  =——s W1BEL@amsat.org ss t—~S 
+(813) 874-2980 Fax:+(813) 872-8696 BBS: +(813) 874-3078 (V.34) 


PacComm Packet Radio Systems, Inc, 4413 N. Hesperides St, Tampa, FL 33614-7618 

From gjones@tenet.edu Mon Feb 27 00:39:00 1995 

Received: from Alice-Thurman.tenet.edu (gjones@Alice-Thurman.tenet.edu 

[198.213.2.5]) by dingus.n5lyt.datarace.com (8.6.9/8.6.9) with ESMTP id AAA11351; 

Mon, 27 Feb 1995 00:38:57 -0600 

Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id 

AAA15814; Mon, 27 Feb 1995 00:37:44 -0600 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199502270637.AAA15814@Alice-Thurman. tenet. edu> 

Subject: Mail Archives available on ftp.tapr.org 

To: netsig@tapr.org (NETSIG mailing), bbssig@tapr.org (BBS SIG mailing), 
aprssig@tapr.org, hfsig@tapr.org (HF SIG mailing) 

Date: Mon, 27 Feb 1995 00:37:43 -0600 (CST) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 215 


Mail Archives for the various mail groups are now available on both 
listserv@tapr.org and via ftp.tapr.org 


The mail archives on the listserv is updated daily. 
The mail archives in the ftp area is updated weekly. 


From mcdermot@aud.alcatel.com Mon Feb 27 07:33:29 1995 

Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com 
(8.6.9/8.6.9) with ESMTP id HAA12840 for <hfsig@tapr.org>; Mon, 27 Feb 1995 
07:33:26 -0600 

Received: by janus@1.aud.alcatel.com id <20494>; Mon, 27 Feb 1995 07:31:38 -0600 
Date: Mon, 27 Feb 1995 07:31:42 -0600 

From: mcdermot@aud.alcatel.com (Tom Mcdermott) 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:284] Indian HF modem 

Message-Id: <95Feb27.073138cst.20494@janus01.aud.alcatel.com> 


Phil: I'll also be in St. Louis, and would like a copy if possible. 


- Tom, N5EG 

From kurpiers@zeus.uet.e-technik.th-darmstadt.de Mon Feb 27 08:42:26 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.9/8.6.9) with SMTP id IAA13594 for 
<hfsig@tapr.org>; Mon, 27 Feb 1995 08:42:06 -0600 
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) 
by rs2.hrz.th-darmstadt.de with SMTP id AA28008 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Mon, 27 Feb 1995 15:40:14 +0100 
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de 
[130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id 
PAA20314 for <hfsig@tapr.org>; Mon, 27 Feb 1995 15:40:13 +0100 
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 
Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-daxrmstad 
(8.6.4/8.6.4) id PAA19390 for hfsig@tapr.org; Mon, 27 Feb 1995 15:38:15 +0100 
Message-Id: <199502271438.PAA19390@hades.uet.e-technik.th-darmstad> 
Subject: Re: Indian HF modem 
To: hfsig@tapr.org 
Date: Mon, 27 Feb 1995 15:38:14 +0100 (MEZ) 
In-Reply-To: <95Feb27.073138cst.20494@janusO1.aud.alcatel.com> from "Tom 
Mcdermott" at Feb 27, 95 07:34:20 am 
X-Mailer: ELM [version 2.4 PL24] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Length: 987 


Hi! 


I also would like to get a copy of that paper. Unfortunatly the conference 
is a bit too far away for me... 


I'm watching this group for some time now and I have to thank you all 
for very interesting information on HF data transmission so far. 


I have done a project on spread spectrum data transmission on HF 2 years 
ago. I had to simulate the modem using the simulation software SPW. 


For proper testing I implemented the CCIR (Watterson) modell in SPW. 


Currently I'm trying to port this channel model to Ptolemy, a CAE tool 


similar to SPW, but PD software. Ptolemy runs under Linux, so you can use 
it on a 486. 


About the HF simulator: I read trough the mentioned paper on a realtime 

HF radio channal analyzer (COM-30, pp. 1809-1817) . Why are they using 
Butterworth filters for the low-pass Gaussian process? Reading through 

the CCIR report 549 I thought I had to use filters with Gaussian frequency 
response. Is this just an approximation? 


73' Alexander DL8AAU 


From FORRERJ@frl.orst.edu Mon Feb 27 12:21:04 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAAOO718 for 
<hfsig@tapr.org>; Mon, 27 Feb 1995 12:21:00 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAA11094 for <hfsig@tapr.org>; Mon, 27 Feb 1995 
02:59:10 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 27 Feb 95 10:19:09 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 27 Feb 95 10:18:54 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 27 Feb 1995 10:18:48 PST8PDT 
Subject: Re: [HFSIG:290] Re: Indian HF modem 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <32B761B3EE3@frl.orst.edu> 


Welcome Alexander! 


< .... some lines deleted .... > 
> 
> I'm watching this group for some time now and I have to thank you all 


> for very interesting information on HF data transmission so far. 


> I have done a project on spread spectrum data transmission on HF 2 years 
ago. I had to simulate the modem using the simulation software SPW. 
> For proper testing I implemented the CCIR (Watterson) modell in SPW. 


Vv 


I wonder if your simulation also included the noise component, i.e. 

stochastic + markov burst noise processes in addition to the fading 

paths? I have a rough idea how that is done, but would like to learn 
more about it. 


About the HF simulator: I read trough the mentioned paper on a realtime 

HF radio channal analyzer (COM-30, pp. 1809-1817) . Why are they using 
Butterworth filters for the low-pass Gaussian process? Reading through 

the CCIR report 549 I thought I had to use filters with Gaussian frequency 
response. Is this just an approximation? 


VV VV Vv 


There is a good reason, just slipped my memory - Hi. I'll get back 
to you on this one. 


73's 


Johan, KC7WW 


From FORRERJ@frl.orst.edu Mon Feb 27 13:22:39 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id NAA0Q1086 for 
<hfsig@tapr.org>; Mon, 27 Feb 1995 13:22:32 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id DAA11105 for <hfsig@tapr.org>; Mon, 27 Feb 1995 
03:00:10 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 27 Feb 95 10:20:08 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 27 Feb 95 10:19:54 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Mon, 27 Feb 1995 10:19:52 PST8PDT 
Subject: Re: [HFSIG:286] No Subject 
Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <32B7A5348DC@frl.orst.edu> 


Bob, 


> 

> Two items of interest: 

>> To be filed with the growing list of affordable hardware options for DSP- 
>> EZDSP-Lab products from Real Time Signal Processing Inc. (403)250-2407, 
>> FAX (403)250-6711. 

>> Stand-alone board with Analog Devices ADSP-2115 and AD1847 Codec for $99. 
>> Price includes PC download utility, Analog Devices' Assembler, Linker and 
>> Prom Splitter but not the Simulator. Don't know what debug environment 
>> is like. ADSP-2181/AD1847 for $199. 


Thanks for that info Bob - I, for one, are always looking. 


> Paper I haven't got yet but looks interesting-- "Soft Decision Decoding of 
> Reed-Solomon Codes Using Trellis Methods" IEE PROC-COMM Oct. 94 
> 


73's 


Johan 
From FORRERJ@frl.orst.edu Tue Feb 28 10:53:46 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAAQ7253 for 
<hfsig@tapr.org>; Tue, 28 Feb 1995 10:53:42 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA17659 for <hfsig@tapr.org>; Tue, 28 Feb 1995 
01:31:40 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Tue, 28 Feb 95 8:51:41 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 28 Feb 95 8:51:12 
PST8PDT 
From: "Johan Forrer" <FORRERIJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 


Date: Tue, 28 Feb 1995 08:51:07 PST8PDT 
Subject: Re: Sound cards 

Priority: normal 

X-mailer: PMail v3.0 (R1a) 


Message-ID: <3420089300D@frl.orst.edu> 
Dear Frode, 


I have some rather sad news about the sound cards: called this morning 
about the whereabouts of the cards and was told that there was no stock 
left when my order was taken - nobody let me know either. Well, what could 
I say - dissapointed of course. The alternative now is to get you an Orchid 
card, such as the one that I got for Adrian for $99. Would that be 
acceptable? I still have the cheque, so feel free to change you mind too. 
Let me know as soon as convenient and I'll do what is necessary. 


I apologize for keeping you waiting - wish I could have done more. 
73's 
Johan, KC7WW 


From FORRERIJ@frl.orst.edu Tue Feb 28 11:23:26 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAAQ7391 for 
<hfsig@tapr.org>; Tue, 28 Feb 1995 11:23:22 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id CAA18012 for <hfsig@tapr.org>; Tue, 28 Feb 1995 
02:01:21 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Tue, 28 Feb 95 9:21:22 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 28 Feb 95 9:21:13 
PST8PDT 
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Message-ID: <34280A72BE9@frl.orst.edu> 
Dear Alexander, 
<... some lines deleted ....> 


About the HF simulator: I read trough the mentioned paper on a realtime 

HF radio channal analyzer (COM-30, pp. 1809-1817) . Why are they using 
Butterworth filters for the low-pass Gaussian process? Reading through 

the CCIR report 549 I thought I had to use filters with Gaussian frequency 
response. Is this just an approximation? 


VV VV WV 


The procedure is as follows (this is performed in triplicate): 


1). Create White Gaussian noise with a given standard deviation as 
determined by the CCIR conditions that you are simulating. 


2). Apply a complex low-pass filter to the points (complex) created 
in (1). A Butterworth response is probably a good choice for 
having low ripple in the pass band. A two-pole filter is quite 
adequate. 

3). Create the Doppler signal (complex) according to CCIR condition. 

4). Perform the complex mix of (2) + (3). 


5). Perform the complex mix of (4) and the signal from the tapped delay 


line. 


Note that for step (5) some further processing is required as you have 

to deal with different sample rates, i.e. the tap gain function at a very 
low frequency while the delay line is sampled baseband. This tells us 

that you probably will need additional interpolation filter in the tap-gain 
path. 


At this point, the model has only done multipath fading, the noise component 
still has to be added. This is a two-component signal, i.e. additive 

white Gaussian noise in addition there should be a Markov process to 
simulate burst noise, these however, are now part of a linear model - 

all the time-variant stuff have been taken care of by then. 


Having both the fading path and the noise path in your simulator, one 
can do S/N performance evaluation in addition to multipath. 


Hope this helps a bit, 
73's 


Johan, KC7WW 


